On the Maximum Availability Architecture website, there’s a paper on <awful term alert>Best Practices</awful term alert> for Database Consolidation. It’s a great paper, as you’d expect from the MAA guys (well, apart from that awful term alert I had to add! 🙂 ). Since database consolidation is an area I work in a lot, I thought I’d start looking at implementing as much of their recommendations as I could in Enterprise Manager, which of course is my tool of choice.
If you look at that paper and its companion paper on MAA Reference Architectures, one of the recommendations they include in the paper is to use Automatic Storage Management (ASM) to provide local mirroring to protect against disk failure. In my test environment, I hadn’t bothered using ASM when I created my test database, purely and simply because the database has no important data in it at all, so if the disk failed I can just recreate it. However, since I’m trying to implement the MAA recommendations, it made sense to start here so I decided to migrate my test database to ASM.
There are a couple of prerequisites you need to have in place before you can start this process. I’m not going to document those in any detail since they’re already documented in the Oracle documentation and many other places, but just to ensure you know what they are, these are the prerequisites:
- You need to have installed the Grid Infrastructure code. Most people tend to think of that as a piece of software you need in a clustered environment, and of course that is one of its main areas of functionality. However, you also use it for ASM in standalone environments (i.e. non-clustered hardware). Installing the Grid Infrastructure also gives you an added advantage – along with ASM you now get access to Oracle Restart. Oracle Restart is a feature that was introduced in the 11.2 code (I think) to automatically restart the database, the listener, and other Oracle components after a hardware or software failure or whenever your database host restarts. More on that later.
- You also need to have configured some disk groups for ASM to manage (see the documentation here for details on how that is done). ASM can use disk partitions, LUN’s, logical volumes or NFS files to build disk groups. In my case, this poor little test environment didn’t have much hardware, so I created some NFS files following the instructions documented here by my good friend Tim Hall.
Once that’s all installed and configured, you are ready to move onto migrating your database to ASM. A note of caution here – this will require downtime for the database.
Migrating the database itself is done from the database home page, so from that page select “Migrate to ASM” from the “Administration” drop down menu:
On the next screen, you will be asked to provide the relevant credentials for the user that owns the Oracle software installation. I already have that defined as preferred credentials for this host, so all I need to do is check the details are correct and click “Continue”:
Next, I am asked which files I want to migrate and the degree of parallelism. I can specify to move just the database files (which in this case includes the datafiles, redo log files, control file and SPFILE) or to move the recovery related files (archive log files and backup files) as well. The degree of parallelism defines the number of RMAN channels that will be allocated for copying the files. In this example, I’ve asked for both database files and recovery related files to be moved, left the degree of parallelism at its default of one and clicked “Next”:
The diskgroups I created earlier were cunningly called “DATA” and “RECO”, so on the next screen I enter the relevant diskgroup names for the database area and fast recovery area, select the “Setup Fast Recovery Area and Migrate Recovery-related Files” radio button and click “Next”:
I left the fast recovery area at its default size, so it prompts me with a warning that the fast recovery area size is less than twice the database size. In my simple test environment, that doesn’t bother me so I click “Yes” to continue:
On the next screen, I can specify a name and description for the job that does the actual migration, and schedule a time for it to start (which defaults to immediately). In this example, I leave these at the defaults and just clicked “Next”:
Finally, I can review all the information I’ve provided and click “Submit Job” to start the migration:
I will see a confirmation that the job was submitted successfully, and can click “View Status” to view the status of the migration job:
This will take me to the Job Activity page. Depending on the amount of job activity taking place in this environment, you can either search for the job or simply scroll through the list and select the job:
On the job execution page, I can select the Auto refresh period on the right hand side, and also choose “Expand All” from the “View” drop down menu so I can see all the details of the job:
All going well, you should see a “Succeeded” message for the status after a few minutes:
To validate the migration has in fact taken place, go back to the database home page, then follow the path “Administration” -> Storage -> Datafiles”:
You should see that the datafile names all now start with the name of the ASM diskgroup (+DATA in my case):
While the database has now been migrated to ASM, there is one more step needed to add the database to Oracle Restart. This step is necessary because the database was created BEFORE we installed the Grid Infrastructure software. To add the database to the Oracle Restart configuration, we use the “srvctl add database” command, and we can then use the “srvctl config database” to confirm it is now under the management of Oracle Restart: