Nate, I'll try to answer each question the best I can:

1. Currently SnapManager creates a snapshot (separate data and log volumes) of our database server. That snapshot is mirrored to a standby server for DR purposes. That mirror is then cloned to another server for restore for consistency checks and internal reporting purposes. Frequently the clone step fails because the data and log volume snapshots are out of sync. If the clone snapshots can be out of sync can the same be true of the mirror? I'd hate to have to fall back on the DR copy to find it's out of sync.

--I'm not sure about this. We could never get cloning to work. My guess is that if the clone is a clone of the mirror then yes, it is possible the mirror could be out of sync. Definitely something worth validating.

2. Removing (and adding) DBs without modifying SnapManager causes issues. We were told whenever we do this that SnapManager has to re-configured. Knowing that then it's not truly volume replication but file replication within a specific volume. Sound about right?

--The SMSQL configuration is separate from SSMS. There is absolutely no integration except it runs a job creation script at the end of configuration. This is one reason why SMSQL is a poor choice for consolidated SQL environments that have databases frequently added or dropped. SMSQL works at the volume level. It is a storage technology - not a database technology.

3. Our previous backup policy was taking a full DB backup on the weekend and differentials/logs during the day/week. Since implementing SnapManager, and because I don't trust a process I'm not in control of, we've switched to a daily full backup because SnapManager updates the last backup date and thus invalidated the (native) full backup. Anybody got a workaround for this?

--I'm not clear how it invalidates the full backup. I can see it breaking the log chain. Not sure. Mixing native and SMSQL is probably not a good idea simply for scheduling reasons though I completely sympathize with your concerns.

Thanks in advance for any replies and if I'm way off base here please let me know. This is a technology I'm not overly familiar with, have limited if any control over and which was "strongly suggested" for us to implement.

-- I've worked at a company with this problem and also consulted with companies with the same problem. Your story is familiar and common to most environments implementing SMSQL. It is usually a top down implementation. Because of major investments in the NetApp storage, companies feel they have to leverage SMSQL (NetApp also sells it to them as a "feature") in order to be consistent with their storage solution. This is the wrong approach and will not scale. It will also put database recovery at risk. I've also seen companies have employees leave because they insisted on using SMSQL. The core problem I've found is a lack of understanding by storage teams and c-level leadership of how databases function. Many times they see no difference between database files and file server.

Good luck and let me know if there is any other way I can help.

Scott

[/quote]