I'm having trouble envisioning a scenario where I would need to have logs available after they've already been replayed into the database. In my specific case, I have an offsite server specifically intended as a lag server for disaster recovery in the event our 2 primary servers become corrupted or otherwise unavailable. I did find a blog that noted: "most sites keep transaction logs around for at least 15 minutes to ensure that they are available if required to bring a database copy up to date should an outage occur." But this doesn't make sense to me -- if I have an long term outage, I will replaly the logs on the lag server and put it into production. Why would I need to delay truncating the logs once it's up and running? Or maybe I'm looking at it from the wrong perspective -- maybe I need to delay truncation on my active servers, and don't delay on my lag server? That way in the event of a short-term outage, I would still have the log files available on the primary servers so I could keep them up to date. thanks

Let's look at Exchange 2007/2010 from afar. Basically, large chunk of the messaging is taken and process in RAM. From RAM, the information is stored into transaction logs, and then transaction logs to DB. Microsoft designed Exchange to use transaction logs to AVOID writing to the DB constantly. As a result, you avoid many issues including corruption, etc. From RAM to transaction logs, the process is automatic. Transaction logs to the DB is not so much. You need to schedule online maintenance on the DB as well as perform full backups to replay the logs onto the DB. To answer your question, once the transaction logs have been played onto the DB, the logs will disappear on their own. As a result, you just need to keep a backup of the DB. I hope this helps!

Jose, that is not 100% correct. Transactions are always written from Memory to DB, not from Logs. (Never Ever from logs). The only time a log file will be read is when we do log replay and then it will be read to memory not DB. The reasons why we keep log files is to ensure we have a record of what happend to the pages of a DB in the event that we have a dirty shutdown. Using the transaction logs we can try and recover these transactions to get the DB in a healthy state as well as roll back transactions that were not completed succesfully. But log files are never replayed during a backup process nor does the online maintance have anything to do with replying log files. But back to the point. During the write of a tranaction to the DB, an transaction is writen to logs first before getting commited to the DB. If the database becomes to busy a backlog of database log files will start to build up (especially if you have very large transactions), before the lazy writer starts to catch up again. In most cases you would not even be aware that is happening, but if you start to truncate log files while you are in a backlog state, you can actually delete log files that are still required. As for your question on whether a DB will actually replay log files that where already commited, no it will not, infact you can delete all logs except the "last log required" as indicated by the DB and you will be fine, but we do recommend that you keep at least 15min worth of logs as you never what log files you will actually need. If I can make a recommendation, go read up on the Lazy writer, CheckPoint and Waypoint. That should give you a good idea what I'm talking about. Casper Pieterse, Principle Consultant - UC, Dimension Data South Africa, Microsoft Certified Master: Exchange 2007 / 2010

Casper, I just basically summarize Microsoft's white paper. So I guess Microsoft is incorrect and you're correct.

Jose, I'm not trying to be funny and would like to make sure that the right info is out there. I'm pretty sure about my facts, but if I'm wrong I need to understand where I made the mistake. Can you point me to the white patper you are refered to?Casper Pieterse, Principle Consultant - UC, Dimension Data South Africa, Microsoft Certified Master: Exchange 2007 / 2010

On Tue, 1 Feb 2011 14:17:15 +0000, Casper Pieterse wrote: >Jose, that is not 100% correct. Transactions are always written from Memory to DB, not from Logs. (Never Ever from logs). The only time a log file will be read is when we do log replay and then it will be read to memory not DB. The reasons why we keep log files is to ensure we have a record of what happend to the pages of a DB in the event that we have a dirty shutdown. Using the transaction logs we can try and recover these transactions to get the DB in a healthy state as well as roll back transactions that were not completed succesfully. But log files are never replayed during a backup process nor does the online maintance have anything to do with replying log files. Changes are very often written to the transaction logs before being written to the database. If that were not the case the ability to defer writes to the database would not exist and the amount of I/O to the database would increase dramatically. When the dirty pages in the buffers are written to the database the information isn't reread from the log files. During backups, writes to the database are frozen and it's possible to exhaust the buffer pool. In that case the modifications are written to the transaction logs and later read from the log files and used to alter the database. Since the database was never altered it can't be said that the log files were "replayed". If the point you're tying to make is that changes can't be read from the transaction logs without first modifying a database buffer you're correct, but that's pretty much the way that any file operation happens, isn't it? >But back to the point. During the write of a tranaction to the DB, an transaction is writen to logs first before getting commited to the DB. If the database becomes to busy a backlog of database log files will start to build up (especially if you have very large transactions), before the lazy writer starts to catch up again. In most cases you would not even be aware that is happening, but if you start to truncate log files while you are in a backlog state, you can actually delete log files that are still required. Yes, you can. That's why I prefer to compress the log files if there's a danger of running out of disk space. >As for your question on whether a DB will actually replay log files that where already commited, no it will not, infact you can delete all logs except the "last log required" as indicated by the DB and you will be fine, but we do recommend that you keep at least 15min worth of logs as you never what log files you will actually need. > >If I can make a recommendation, go read up on the Lazy writer, CheckPoint and Waypoint. That should give you a good idea what I'm talking about. > > >Casper Pieterse, Principle Consultant - UC, Dimension Data South Africa, Microsoft Certified Master: Exchange 2007 / 2010 --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Here is one source: http://www.msexchange.org/articles/Transaction-Logs-Lifeblood-Exchange.html.

In part three of this multi-part article, we created the log and database LUNs, changed the path for the logs and databases, created the DAG, and added the servers to the DAG. South Beach Java

In your very first line you wrote Transactions are always written from Memory to DB, not from Logs. (Never Ever from logs). but in the next paragraph you wrote But back to the point. During the write of a tranaction to the DB, an transaction is writen to logs first before getting commited to the DB. If the database becomes to busy a backlog of database log files will start to build up I read that right at the time and just decided youd mis-written something or decided to edit the very first sentence. I was happy you didnt need correcting at the time because your subsequent sentence was correct. The problem being most people on the forums arent Exchange uber-experts (by very nature of them asking a question). You just have to be careful what you write and quickly correct something if it ends up not looking like what you meant. Ive had to do that more than a few times over ten years so Im not being snippy! "Casper Pieterse" wrote in message news:67574202-9ee9-4d68-9855-a8ba26fa65b4... Jose, I'm not trying to be funny and would like to make sure that the right info is out there. I'm pretty sure about my facts, but if I'm wrong I need to understand where I made the mistake. Can you point me to the white patper you are refered to? Casper Pieterse, Principle Consultant - UC, Dimension Data South Africa, Microsoft Certified Master: Exchange 2007 / 2010 Mark Arnold, Exchange MVP.

Mark and Casper: "Before changes are made to an Exchange database file, Exchange writes the changes to a transaction log file. After a change has been safely logged, it can then be written to the database file. It is common for these changes to become available to end users just after the changes have been secured to the transaction log, but before they have been written to the database file. Exchange employs a sophisticated internal memory management system that is tuned for high performance and can efficiently manage the caching of dozens of gigabytes (GBs) of database pages. Therefore, physically writing out changes to the database file is a low-priority task during normal operation. If a database suddenly stops, cached changes are not lost just because the memory cache was destroyed. When the database restarts, Exchange scans the log files, and reconstructs and applies any changes not yet written to the database file. This process is called replaying log files. The database is structured so that Exchange can determine whether any operation in any log file has already been applied to the database, needs to be applied to the database, or does not belong to the database." Source: http://technet.microsoft.com/en-us/library/bb331951%28EXCHG.80%29.aspx.

So let's summarize to end of this thread: The process is (more or less) this: 1) User / System Initiates a transaction that requires DB change 2) Exchange takes required page(s) from db and load to memory, marks the page as dirty in memory. 3) Exchange makes changes to page in memory and writes the updated page to the transaction log as well (with other info) to disk 3b) User immediatly sees change as user connects to memory, not DB. 4) Exchange writes updates page (s) to db and marks the page as clean. 4b) Exchange updates Last Log Required DB value. At this point, any transaction log prior to last log required can be safely trunacted. If the DB is very busy, steps 4 and 4b will be be throttled, thus causing a backup in logs. If the last logs generated was to be truncated at this stage, should an unexpected error occur, we will not have the required logs to bring the DB back into a healty state. My words of "(never ever)" was incorrect, it should have stated "never ever during normal operations" :-) Apologies if it caused confusion.Casper Pieterse, Principle Consultant - UC, Dimension Data South Africa, Microsoft Certified Master: Exchange 2007 / 2010

No apologies; go Exchange!