Favorite way: migrating to exadata
Tags:
Microsoft Sql Server,
Technical Track,
Sql Server On Linux,
Sql Server Administration,
Sql Server Configuration
There are lots of considerations to be taken into account when migrating databases to the Exadata. It's like any other migration. DBAs and other stakeholders of the system have to evaluate what to migrate and what not to, physical and logical settings, versions and many other things.
I'm not delving into migration preparation or strategies and methods here, instead I want to mention which method I like the best to migrate databases to the Exadata. By doing it this way you can make the source database primary in Dataguard configuration and creating a physical standby on the Exadata, and then switch-over the primary to Exadata. How's that? Neat, simple, quick and beautiful. Generally, these steps would be followed to accomplish this physical approach of
migration:
- At source database, enable the force logging, put it in archivelog mode, set secondary archive destination, add TNS entries and add standby redo logs etc.
- At Exadata, make sure ASM instances are up and running.
- At standby side, create a simple parameter file, make entries in TNS, and then start standby instance in nomount.
- Then from primary, in RMAN, connect to the source database and with target auxiliary standby and run duplicate target database for standby from active database.
- Then after making sure that standby is in sync with primary, switch-over to the standby.
- Using srvctl register this database to clusterware at all nodes of Exadata and configure database as RAC.
- Point your applications to the new Exadata database.
