Our vCenter server's Oracle database was growing at an alarming rate, and it was causing vSphere connections to crash intermittently. I found this to be very annoying and since I'm more of a SQL guy anyways (and no one in our office is an Oracle expert) we decided to plan for migrating off Oracle to SQL.
I researched for days trying to find out if someone had posted specific steps on how to successfully migrate a backend vCenter database from Oracle to SQL Server. I found multiple threads referencing links that eluded to how difficult it is, how there's no one tool that guarantees success, but I was floored to discover that not a single person has written anything on exactly "how to do it." So I decided to write up a little guide containing the steps I used to do this exact migration just last week. This pertains to Oracle 11_g to SQL 2008 R2. Theoretically the following steps should work as long as the SSMA tool can communicate with both the source and target servers.
Yes, I used the Microsoft SQL Server Migration Assistant tool. Before starting this migration, familiarize yourself with: Getting Started with SSMA for Oracle(OracleToSQL) and all the subsequent links. I installed the extension pack on the target SQL server and on the oracle backend server just to be safe. Installing SSMA for Oracle(OracleToSQL). I then installed the client to the Oracle server. FYI, you have to obtain a license for SSMA...don't worry though, it's free.
Now for the fun part. I'll walk you through the general timeline of events so you can get a feel for how this went. Plus then you can avoid the trials and tribulations I went through.
The SSMA tool will "copy" data from the Oracle database to the SQL database. This means that it's got to have a database structure to copy to. This is achieved by first creating the VCDB database on the target SQL server. So what I did was first create a blank VCDB database on the target SQL server, then install another vCenter server and pointed it at the empty VCDB database. Once the installer finishes you will have a "template" to copy the data to from the Oracle instance. This is an important step and must be done otherwise it won't work. Also note that the copy process will OVERWRITE existing data...so keep that in mind as you continue reading.
Once the VCDB template is in place, launch the Oracle client from the Oracle server and begin a new project. Connect to the Oracle instance, then connect to the target SQL instance. It might take a while for the Oracle schemas to load. By default the "schema" you want to migrate the data from is the 'VPXADMIN' schema. At this point I changed the properties in the schema to modify the target schema and selected the dbo.vcdb schema. If you don't do this it'll try and write to the vpxadmin.vcdb schema and it just doesn't exist.
Now, because the structure (template) is already in place, all I wanted was the data from the TABLES. So I selected the tables folder, and began the process of migrating (yes overwriting the existing data). I would refresh the target server and saw the vcdb.mdf file growing so I knew I was connected to the right instance. This took literally 6-7 hours to complete. I got notified that 4 tables weren't migrated due to various reasons but after researching them I figured they weren't that big of a deal anyways. These tables were:
• VPX_PARAMETER
• VPX_EVENT
• VPX_EVENT_ARG
• VPX_MANAGEMENT_INFO
I did some more digging and discovered that if I first converted the specific table in the SSMA tool, then migrated the data...it worked better. So that's what I did with the VPX_PARAMETER table. I then found that the VPX_MANAGEMENT_INFO table didn't exist in the original VCDB database that got created anyways, so I guess it's not needed in the SQL instance. The other two event tables contain event information that's occurred over time.
I contemplated this and did a bit of research and decided that the above tables weren't going to hinder things too bad, so using the guide http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028601, I modified the registry on our vCenter server and attempted the first connection to SQL. Service failed to start. I then ran "vpxd -s" and saw that it was indeed connecting to the ODBC connection, but it was failing to open the database with an error pertaining to an incorrect sequence. I figured it had to do with the 4 tables that weren't migrated, so I converted the Event ones and migrated data there. Same result. I then researched more and ultimately discovered that the VPX_SEQUENCE table on the Oracle server was empty.
Ok, so I then ran a "vpxd -b" from the vCenter server. This is the proverbial database "reset" switch to use and it basically recreated my VCDB template. So yes that meant I had to migrate again...joy. But this time I knew the the tables that were going to fail anyways so I just left them unchecked. But before I started the next round of migrations, I checked the VPX_SEQUENCE table that was just re-created...and it had content/data in it. So I added that table to my "unchecked" list and ran the migrations. This time it took less than an hour to complete. HUGE difference...probably because of all the events. I then converted the VPX_PARAMETER table and migrated that data. I did the same for the Event ones too, but only migrating a portion of the data, not all of it. After all, it's just event data...
2nd attempt at starting vCenter...failed. Watching "vpxd -s" again, this time it was failing because of an improper "schema hash mismatch." Researched some more, reset the VCDB template again...and found the VPX_SCHEMA_HASH table. I compared the data between the Oracle version and the SQL version, and sure enough they were different. I then unchecked that table for migrations... So at this point tables I'm NOT migrating are:
• VPX_SCHEMA_HASH
• VPX_SEQUENCE
• VPX_EVENT
• VPX_EVENT_ARG
Third round of migrations...again took less than an hour. In fact this time it took roughly 20 minutes. So with those tables de-selected I cut the time down from 7 hours to 20 minutes. Fingers crossed and preparing for researching another error, I started the vCenter service...and it worked! I logged into vSphere and all the cluster settings, hosts, VMs, etc ...everything is all there! Party time!
So to recap and summarize, here's what you do:
** Create a blank VCDB database on the target SQL server. Then, install vCenter on another VM that can be deleted after this migration, but aim it at the target VCDB database you just created...this will create the template VCDB. In our case I just temporarily installed another vCenter instance on my target SQL server.
** Create a new ODBC connection on the vCenter server and configure it for the VCDB database on the target SQL server. Then proceed:
1. Download and obtain a license for SSMA (Oracle to SQL)
2. Stop all vCenter services (you can also snapshot the vm’s to be safe)
3. Change the ODBC registry entries on vCenter server:
To update the ODBC connection:
a. Click Start > Run, type regedit, and click OK. The Registry Editor window opens.
b. Navigate to HKEY_LOCAL_MACHINE > SOFTWARE > VMware Inc, VMware VirtualCenter > DB.
c. Modify Key 1 and change the ODBC driver to the new driver. (SQL Server Native Client 10.0)
d. Modify key 2 and add the vCenter Server user, for example sa.
4. Install SSMA extension pack on target SQL server (it'll create some other databases FYI)
5. Install SSMA Client on Oracle server and launch client
6. Create an SSMA project and connect up to the Oracle source and SQL target servers
7. Select the VPXADMIN schema in the Oracle Instance and change the target schema to “dbo.vcdb” in the VPXADMIN properties
8. Under the Oracle schemas, expand the tables for the "VPXADMIN" schema andde-select the "VPX_SCHEMA_HASH" and "VPX_SEQUENCE" tables at a minimum. (I chose to not migrate the event data just because it contained so much data so that's up to you…aka VPX_EVENT, VPX_EVENT_ARG)
9. Migrate the table data to the SQL target
10. After those migrations are completed, select ONLY the VPX_PARAMETER table from the Oracle VPXADMIN schema, and “convert” it to the SQL dbo target schema…then migrate just that particular table data.
11. On the vCenter server, update the ODBC password by running “vpxd –p”
12. Start the vCenter services. Verify everything works.
If it doesn't, you can always change the ODBC registry info on the vCenter server back and re-aim it at the Oracle instance to try again another day. You can also "reset" the VCDB database by typing "vpxd -b" from the vCenter server.
DISCLAIMER: The above steps worked for me in my particular situation. This by no means is a guide for every possible scenario. That said, theoretically the above steps "should" leave you with a stable vCenter environment after migrating from Oracle to SQL. I just thought I would contribute my experiences since I could find no other online resources detailing what steps people used to do this.
If there are any other recommendations or concerns about these instructions, please do not hesitate to post up. Thanks for reading and good luck if you have to do this!
references:
http://communities.vmware.com/thread/213592?start=0&tstart=0
VMware KB: Migrating the vCenter Server database from SQL Express 2005 to SQL Server 2008
How to migrate database from Oracle to SQL Server? - Stack Overflow