DC Migration (SAN Level Copy)

P

Pradeep Sh

New Member
Hi All,

We are in a process of DC migration. We are planning to have a SAN level copy of all the DBs and then move that SAN to Target DC.
I am in doubt that when SAN team will perform the copy of data, do we need to have a outage or down time for Databases for consistent data. Or just base line snap mirror will work and we will be able to bring up the databases at target databases.
Plan:
Source DC SAN --> Copy --> Temp SAN --> Move SAN to Target --> Target DC SAN (Bring Up the DB)

Here when we are doing copy to temp SAN do we need to bring down the database or do Proquite for consistent data.

Any help will be valuable for me.

Let me know if more details are needed.

Thanks a lot!
Pradeep Sharma
 
What is meant by "DC"?

You do not mention your Progress version. That could be important. You have also failed to specifiy the OS and the brand of SAN hardware. Those are important too.

Progress has certified OpenEdge 10.1C with EMC's SRDF "snapshot". So if you have those products and they are properly configured you might be ok.

The safest way to do this is to first shutdown the database. Since you appear to be planning on bringing up the db on a new server you are going to have to shutdown anyway so I'm not sure why you would be considering proquiet -- it would add no value to this process.

Is there a reason why you are not simply backing up (with probkup) and restoring?
 
Hi Tom,

Thanks alot for replying.

DC -- Data Center

We have different vesrsions of Progress Starting form V7, V8, V9 and V10 also. OS we have AIX, HP Unix, Linux and Windows.
SAN hardware, HP Netapp.

Our plan is to copy all the data to SAN and then physically move that SAN to target DC which will take few days and then connect that SAN to servers and bring up the Databases. So I was planning to do proquiet or DB down at source DC while SAN level copy for data consistency.
Could you please let me know if this is necessary to do, will data not be consistent if we will not do DB down.

Please let me know if am missing something.

Thanks alot...

Pradeep Sharma
 
1) The databases need to be quiet for OS or SAN level copies to be valid. You cannot make a "live" copy of Progress database using OS tools and expect it to work properly.

2) After the move you will restart the databases on new servers in a new data center.

3) Therefore it seems obvious that you should shutdown on the old servers and the old SAN, do the copy, and then restart on the new servers.

4) If you do not shutdown and merely do a quiet point you will a) have more work since you must monitor the .lg file to ensure a quiet point has actually started (getting a command prompt back after "proquiet" is not sufficient) and b) if you release the quiet point and continue working you will have data on one system that does not migrate to the new system.

5) If you need to minimize the downtime window you could use after-image files to "catch" up. But those steps aren't shown in your original proposal and would require extra preparation and coordination. Judging from the fact that you are asking the level of question that you are asking that is probably beyond the scope of your current capabilities. You might want to engage a consultant if you need to do that.
 
Hi Tom,

Greetings

I just wanted to know if we will not shutdown the databases and will do a SAN level copy while database is online, we might get inconsistent copy and we will try to bring up the databases at target data center, the progress engine will behave like as there were a power outage and go through the crash recovery and bring up the database.

I know this is a risky step but is it possible to do in this way.

Please give me your valuable suggestion.

Thanks a lot
Pradeep Sharma
 
The problem with OS level copies of running databases is the fact that parts of the database are stored in shared memory and are flushed to disk by background processes. That Progress takes care of so you don't need to worry in case your database crashes - as you mentioned the crash recovery. But when the database gets changed all the files that belong to the database (before image, data, after image) are kept in sync with a time stamp. A matching time stamp ensures that data has been written consistently to the files on disk - while a mismatching time stamp indicates that they were not ...

Therefore if you use OS copy of a running database while the database is changed it is almost 100% sure your copy won't be a valid database because the time stamps won't match as an OS copy will copy the files sequentially. You might be lucky succeeding with an OS copy if the database is not changed at the time you are doing it. But I would not consider this a fair chance - more like a lottery jackpot ...

SAN snapshots are a little bit different for that matter, but as long as it's not supported from the technology vendor (Progress) I would never, never, never risk production data on a SAN vendor's promises - I know they promise they can do that but rarely have I seen cases where SAN vendors were able to keep up with their promises.

Regards, RealHeavyDude.
 
As RHD said.

Taking an OS or SAN copy of a running db is not going to work consistently. It might appear to work once in a while but you cannot trust it. It is not the same as a crashed db -- it is a corrupt db which you cannot recover.

It also makes no sense at all for the scenario that you have described. I do not understand why you keep pursuing it. It saves you no time -- you have to shutdown and restart anyway; and it only exposes you to a very high probability of a corrupt database. If you have someone pressuring you to do this you need to say NO in a very clear voice.
 
Hello Sir,
I read above discussion and have a question in my mind that if you don't want to shut down the database then can you use the after image concept.
after sync completes you can do proquite +split+ note the Ai file number+ move the san copy physically+ apply ai files after the noted num. once DB is in sync
you can do migration. but you are not applying this so i doubt for the reason.

thanks
Abhay
 
You must log in or register to reply here.
Back
Top