I’ve been reading the TimeFinder Integration guide for SQL and Exchange – this is going to be FUN…. (not)
it would be nice if, at least from the SQL standpoint, they do transaction logging in the traditional sense, so that I could just snap the database, snap the transaction logs, and back the flat-files up.
What MS seems to want, is for you to snap the database and logs, and then mount them on a remote SQL system and back it up using the SQL tools, which is just about 10 more steps than should be required to perform this.
Why does Microsoft feel it necessary to complicate things so painfully?
4 comments
Skip to comment form
Really? I know with the Netapp software they just queisce the database, take a snapshot, make a copy of the transaction logs, and that’s it. Unless it’s a “verified” backup where they will mount the snapshot version of the luns and run DBCC against it. Exchange works the same way, though the integrity check is run with a different tool (I’m not the Exchange guy, something I thank the Lord for every day). We do this on the same servers.
Author
The utility is ESEUTIL – it will check the consistency of the database and let you know what transaction logs you will need to recover.
I’m not the exchange wonk, we fired him a couple of months ago. However Exchange seems to be more like a “real” database than MSSQL is.
Back in my oracle days, and this worked for DB2 as well, it was easy.
First you put the database in hot backup mode, or write suspend it, or whatever the term is.
Then you snap the database, ensuring a clean copy of the datafiles.
Then you resume the database and issue a log_switch command. (at least in DB2 you do, don’t recall oracle as working with Microsoft on a day-to-day basis has been like getting a lobotomy, a little at a time) – the log-switch makes sure that the transaction log file that was active when you split the database is closed cleanly before you split the log volume.
Then you split the log volume and mount both the data volumes and log volumes on the media server and back up the flat files.
From the EMC documentation, which I know is in and of itself a contradiction in terms, I’m led to believe that they want you to actually mount the database on the target system and back it up using the SQL agent. This seems horribly wasteful, as that means that the calls to the database to back it up are still going through the listener and are not bottlenecking you.
I understand the need to do that in exchange if you are wanting to use single item “Brick-Level” restore, because the only way to back up the individual rows in the database is to query it.
I plan on getting through it this week, though my new media server won’t be here for some weeks, I’ll figure out a way to deal with it.
Ha! Great analogy. Working with Windows is like getting a lobotomy, a little bit at a time. Very insightful. 🙂
I think “Quiesce” was the state you were looking for. 🙂
Netapp’s product (SnapManager) does all of that. The lobotomized individual just has to set up a schedule. You can even tell it which server to run the verification checks on.
And I think many would take issue with calling Exchange’s butchered JET database a database, let alone better than MSSQL. Of course, the Oracle and DB2 guys would probably lump them together. 🙂
Author
LOL – I didn’t say it was better than MSSQL, just easier, and more like a “real” database, from the standpoint of backing it up. You snap the database, run ESEUTIL to verify the status and the existence of the correct logfiles, then you roll-the logfiles forward and bingo, you’ve got an up-2-date restore.
Quiesce is the oracle term? In DB2 it’s “Write-Suspended”
The cool thing is that oracle can sit in hot backup mode indefinitely, provided you have space for the transaction logs. DB2 utilizes a “buffer-cache” and write-suspends both the data files *AND* the log files. When the buffer cache fills, the database crashes, and the resume gets updated.