« Moving Objects To New Tablespace | Main | How To Import Data From a File To A Table Using PL/SQL »
December 9, 2010
Movin' On
Well, it's time to bid farewell to Sundown, our workhorse Sun server that houses the production Oracle database and many other critical services for campus. I kind of hate to see it go - it has been an extremely reliable platform with plenty of horsepower and a couple of humongous storage arrays hooked to it. But, as everyone knows, nothing stays put for long in the computing world. So, Sundown is going to be replaced with a Solaris LDOM (much like a Windows VM) - actually, two LDOM's.
Michael Ellis and I have been work, work, working on Aero to get it ready to move. This included such things as cleaning up old schemas, removing unused tablespaces, and general db housekeeping. It is now in pretty good shape.
The process for moving an Oracle db from one server to another is a pretty good challenge. Luckily for us, we are maintaining the same OS (Solaris 10, 64 bit), and we have configured the new LDOM to mirror the existing file structure. I installed and patched the same software version onto the LDOM, so now we just need to move the database.
I have gained a better appreciation for the difference between the "binaries" of an Oracle install, and the "database". The binaries includes all of the software (Explained to me as the Car. The database is the Gas.) So we have this Car sitting there on the LDOM, which for all intents and purposes is a mirror of our existing production database. Here's how we fill 'er up, then start the engine.
First, shutdown the existing db with shutdown immediate (not abort). Then copy the database files, control files, and redo files over to the LDOM. Tweak the initaero.ora, listener config, shell (environment variables), tnsnames.ora, and probably one or two more files to reflect the new server's name.
Once all this is in place, we "startup mount pfile=path/initaero.ora" and see what happens. In practice we have always forgotten a parameter or two, or something, but the db will tell you why it can't mount. You fix the problem, then try again. Pretty soon, the db will mount. Then, it's "alter database open". With a little luck, what you now have is the production db sitting on your new server.
This is one of those situations in life where you can describe the process pretty easily. However, actually making *everything* work upon the move is way more complicated. The production db has tons of bells and whistles, special cases, and add-ons that have been configured over time. Each of these needs special attention.
Stay tuned for the movement of the HTTP Server (thanks Ron), and the process for moving the dictionary objects to a new file system.
Posted by rossm at December 9, 2010 10:37 AM
Comments
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)