lots of details in there that should answer most questions. You can also check out the object data model document on the Documents page of www.CiscoUnityTools.com - it covers a lot of high level data design that may be helfpul.
Not a good idea to turn the jobs off - we add them there for a reason. It shouldn't cause any problem (it hasn't to date and we've had that in place from day 1 with the SQL back end).
The maintenance guide has details on how to move the SQL transaction logs and such - should be no problem here.
The rest I don't know about - I'll forward the link to the DB boys to see if they have comments on them.
1. You can use Enterprise Manager to look at the job details. We have two jobs by default; they are for emergency DB backups (like if you accidentally type "delete subscriber" in isqlw ;). Unity doesn't need them to function but as long as they aren't hurting anything you might as well leave them on. Their impact on performance is minimal.
2. Not really... Try CUDLE as Jeff suggested
3. Theoretically that should be OK but I suggest not messing with it because it is not a tested configuration. It shouldn't make a noticeable difference in performance.
4. IIRC, we punt on this one... If a supported third-party backup solution recommends one over the other with their particular product, trust their judgement.
5. The DB does differential backups through the week but starts with a clean slate with a full backup on Sundays at 2am (adjustable in EM for those so inclined).
6. As Jeff mentioned, this is documented in the Install guide.
Other than #6 and possibly #4, we strongly recommend not messing around with the SQL configuration. All our performance and QA testing assumes the shipping configuration.
I should have mentioned that this Unity configuration is utilizing Unity failover. The customer's SQL staff monitor all SQL servers daily to ensure all SQL jobs have run. Are the specific jobs that SQL runs for replication between Unity servers that they could monitor on a daily basis?
I noticed that the Unity maintenace plan in SQL for the Unity and Report database does not allow for truncating transaction logs. The transaction logs are 4GB and growing (Not Good!) If you look at the maintenance plan under the transaction log tab, where you would configure the amount of days to keep log files is set to Zero and you can't change it (It's Blank).
This is again a failover configuration and prior to that they had only one voice mail server. The flavor of SQL installed initially was MSDE. To go to failover we had to upgrade to SQL 2000. I am only mentioning this because it initially had MSDE.
Actually Unity doesn't ship with a default maintenance plan... the transaction logs are truncated as part of the backup operations performed by the nightly and weekly jobs.
You can see the jobs in Enterprise Manager under Management->SQL Agent->Jobs. The SqlServer Agent service must be running for these jobs to kick off. You can right-click them to view their success/fail history. It sounds like they might not be running.
It's possible that the nightly and weekly jobs are failing. Check your event logs. There should be something in there every night around 2AM (assuming you haven't changed the defaults). If you are getting failures on either of the jobs, make sure that the recovery model for Unitydb is set to FULL.
If you end up changing the recovery model, you need to run the Weekly job (full backup) manually first - otherwise, the nightly job (incremental) will fail.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...