there is no "recommended" size for transactions logs .ldf or databases .mdf in SQL server. SQL Server autoshrinks databases that have a large amount of free space. Only those databases where the autoshrink option has been set to true are candidates for this process. The server checks the space usage in each database periodically. If a database is found with a lot of empty space and it has the autoshrink option set to true, SQL Server reduces the size of the files in the database. You can also use SQL Server Enterprise Manager or the DBCC SHRINKDATABASE and DBCC SHRINKFILE statements to shrink the files of a database manually.
Files are always shrunk from the end. For example, if you have a 5 GB file and specify 4GB as the target_size in a DBCC SHRINKDB statement, SQL Server will free as much space as it can from the last 1 GB of the file. If there are used pages in the part of the file being released, SQL Server first relocates the pages to the part being retained. You can only shrink a database to the point where it has no free space remaining. For example, if a 5GB database has 4 GB of data and you specify 3 GB as the target_size of a DBCC SHRINKDATABASE statement, only 1 GB will be freed.
If a DBCC SHRINKDATABASE or DBCC SHRINKFILE statement cannot reclaim all the space in a log file, the statement will issue an informational message indicating what action you must perform to make more space eligible to be freed
like with exchange, deciding which partition to put transaction logs on or separating transaction logs from the database files means NOTHING unless they are different PHYSICAL disks. I you have this luxary, then by all means take advantage of it.
"You might want to take a look at "White Paper: Physical Storage Best Practices for Cisco Unity with Microsoft Exchange," "
i guess this white paper would be informative however since he was asking about SQL it would be less so in this case. SQL, while having some paralells with exchange, is a different database.
Exchange transaction logs grow to 5mb and then a new one is created and so on where SQL maintains one continuous transaction log. Exchange transaction logs are truncated with a full database backup where obviously SQL's are not.
Your best bet with unity in my opinion is to leave things how they are unless you can move the transaction logs to a different physical disk or physical array
then your .mdf's and still you will not really notice a difference since you will not be constantly accessing data from this database like you would with a SQL server that was serving another enterprise data storage role.
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...