HPE Storage Users Group

Curious if it is necessary to replicate TEMP? Seems like it would generate a lot of IO not needed to recover a database to last committed transaction. I am guessing it is probably wise to do so if for no other reason than to make sure the fail-over could be automated and all the expected files were at the DR site that the instance was expecting.
Ken

I assume you mean TempDB? TempDB is reinitialized every time SQL starts up so it has no volatile data in it. We actually only replicate the TemptDB, and pagefile drives once a day to make sure they pick up any logical OS drive size changes, the OS, data and Log drives get replicated every 15 minutes. and we do with with well over 100 SQL servers for DR.

Right, TEMPDB. When you only sync once a day though does that really reduce the amount of data sent in total? I mean won't the 3PAR save up all the changed blocks from that VV and just send them over once a day instead of every 15 minutes?

Basically in Periodic only the differences that exist at the time of the sync are sent, so if the same blocks changes dozens of times between syncs only the latest state of the blocks is sent. In Synchronous every block change is sent immediately. So since TempDB tends to thrash by nature we use infrequent replication just to make sure the current state of the volume is replicated, not the data itself.


From the HP Remote Copy User Guide:

Snapshots in Asynchronous Periodic Mode
In asynchronous periodic mode, remote copy creates snapshots as part of normal operations.
Snapshots are used to locate the data written between two synchronizations.
Snapshots Taken during Initial Synchronization
During the initial synchronization, HP 3P AR Remote Copy:
1 . Takes a snapshot of the primary volume .
2. Sends that snapshot over to initialize the secondary volume .
Snapshots Taken during Resynchronization
At the next scheduled resynchronization, or whenever you issue the syncrcopy command, HP
3P AR Remote Copy:
1 . T akes new snapshots of the secondary and primary volumes.
2. Sends the differences between the old primary snapshot and the new primary snapshot over
to resynchronize the secondary base volume .

Thank you, makes sense.

Since it's reinitialized on restart we never replicate TempDB. We just have the drives pre-set at the replication site and update sizes if needed. It's more automated to do it the way hdtvguy does it though.

JasonAntes wrote:Since it's reinitialized on restart we never replicate TempDB. We just have the drives pre-set at the replication site and update sizes if needed. It's more automated to do it the way hdtvguy does it though.

That is an option as well, we were trying to minimize the potential of admins forgetting to update DR side.

no need to replicate tempDB. When you fail over and the instance is started at the DR site it is wiped clean. The DR instance just has a blank/placeholder tempdb for when the instance starts.

Correct, but we use VMDKs and so if someone grows the drive we need to make sure the vmdk is replicated so as a safety measure against human error we replicate it once a day.