Based on perfmon we are having disk utilization problems, mainly high Avg Queue Length on the database drive. We are about to reconfigure our DASD to 2-9GB drives RAID1 for the OS (C:),5-73GB drives RAID5 for the tempdb and database (D:,E:,F:) and 2-36GB drives RAID1 for the transaction logs (H:). Would be interested in hearing from others on their configs or issues. The root cause seems to be the large number of rows written to the Logger every half-hour and the real-time reports on the HDS. We are also adding more DASD in preperation for upgrading to SQL 7.0.
This sounds like the right way to go for such a large DB, especially with SQL 6.5. You might consider even having the tempdb on the H: drive as well, and leave the "normal" DB trasactions on the RAID 5 array. Either way, is there a reason you're going with such a large usable drive (36GB) for that? How large are your transaction logs? I know that smaller drives are becoming scarce, so that may be the reason. ??
Our DBA wants the transaction log on a different array than the DB. Our transaction logs are only sized for 600MB, but we are reusing the 36GB drives that are currently supporting the DB and being replaced by the 73GB ones. Also, as you stated 9/18GB drives are hard to find these days. Thanks for the response.
We just added 140GB to our HDS Servers each. We are retaining 60 days worth of data from the ICM and are at 32% capacity. It is my understanding that the transaction logs should not be more than 200MB in size. Have you run into any issues with a 600MB transaction log? This information was relayed to me from TAC when I had one of the HDSs' crash after expanding the database and increasing the transaction log from 200MB to 3GB.
Unfortunately, you will probably get a different answer on transaction log size depending on who you ask. The ICM team continues to discover more about database sizing with more testing and more field experience with customers like yourselves running much larger databases than we normally see.
You probably know that our database tools default to a 100MB transaction log for a Logger ("SideA" or "SideB") DB when you create a new one. I think the current tools default to a 200MB log for a Distributor - HDS I'm not sure. Anyway, the current "best practice" thinking that does in fact come from the TAC and engineering is that the transaction log for any ICM database should be *at least* 200MB, and that having one that's larger, not necessarily proportional, is not "unsupported" by any means. I think 3GB is probably overkill, even for a 140+GB database. 600MB, however, is not. It really depends on how often (hopefully not very, if ever) you are experiencing transaction log filling that stops the DB processing.
Another factor here is SQL version. 6.5, I think, is fairly notorius for having poor transaction log management. 7.0 is a little better, but I also think that 7.0 can be a little more memory and processor intensive for the same DB size and parameters. I guess it's probably doing more arbitrary maintenance for stability's sake, at the cost of a little more mem and CPU cycles.
We have had to increase the size of the transaction log several times in the year and a half that we have been in production. The log kept filling and locking up access to the db from our AWs. The TAC has loaded a utility that makes sure that the log soes not get to 100% and we have not had any problems at 600MB. Our db is sized for 100GB currently and we are running about 65%.We started at 30GB about a year and a half ago. We are currently retaining 150 days worth of Route_Call_Detail and Termination_Call_Detail data on our HDSs. We are in the process of starting daily extracts off the HDS to a central db that will also store IVR and desktop application data to capture the complete experience of the caller.
The TAC and our internal DBAs had advised that with SQL 6.5 and NT we probably should not go over 100GB for the db size.
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...