vmproteau
Enthusiast
Enthusiast

Multiple vCenter Databases on the same SQL Instance

Jump to solution

I know this is possible, my question is specfic to the rollup jobs created (I think during the schema updates).

I have asked our DBA to create a Lab vCenter DB and a Lab Update Manager DB on our SQL2008 server using the scripts outlined in the ESX and vCenter Server Installation Guide (I'll be using new unique Lab DB names and Lab DB SQL users). This SQL server instance already has a production vCenter DB and production Update Manager DB.

My question is what happens with the schema updates when I let the Lab install do the schema updates.

  1. Do I have to do anything prior to installing vCenter to avoid potential conflicts on the DB side?
  2. WIll the schema updates attempt to recreate the rollup jobs and fail, break the existing jobs, or somethign else?


I'm looking for best practice so that when I install the Lab, the existing production DB environment (including rollup jobs) are not affected and new Lab rollup jobs are created function properly.

I'm not a DBA so if I'm way off feel free to correct me.

0 Kudos
1 Solution

Accepted Solutions
Troy_Clavell
Immortal
Immortal

The install created the names.

View solution in original post

0 Kudos
11 Replies
Troy_Clavell
Immortal
Immortal

at time, not so long ago, we had 9 vCenter and 9 VUM Databases all running under the same SQL 2005 Enterprise 64bit SQL Server.  Today, it's 4vCenters, a couple VMware View Composer DB's and a few VUM instances.

With that said, the greatness of SQL Server is you can run multiple instances under one SQL Server.  So, when it comes time to do schema upgrades you'll only upgrade the schema of the instance in which you have an ODBC connection to.


I wouldn't worry to much about the rollup jobs.  Those are just functions of SQL.  They do get created when you install vCenter and connect to a SQL Server, but can always be recreated very easily.

vmproteau
Enthusiast
Enthusiast

So how do those jobs function? Again forgive any SQL ignorance here.

Will one set be used for all vCenter instances on an SQL Instance? My confusion is how they are used. Are the jobs associated with multiple databases (i.e. they are scheduled to run and somehow know which databases to run on)...

...or are the databases themselves configured to call the jobs at certain times?

0 Kudos
Troy_Clavell
Immortal
Immortal

rollup jobs are associated with vCenter DB instances only.  Each vCenter DB instance has it's on set of jobs.

vmproteau
Enthusiast
Enthusiast

Thanks. I was still wanting to understand more fully what happens when a 2nd (or more) install happens on the same instance.

I assume one of these would happen when installing a 2nd vCenter on an SQL instance:

  1. The install somehow avoids any potential conflict with respect to rollup jobs. Each install has it's own jobs and everything functions fine.
  2. The 2nd install breaks the first DB's jobs and we'll need to manually recreate one or both sets.
  3. The 2nd DB's jobs don't get created correctly and we'll need to manually recreate one or both sets.

If it's 2 or 3, I would just want to write up a best practice process for my team when dealing with the situation.

0 Kudos
Troy_Clavell
Immortal
Immortal

SQL Server is just an application at a high level.  Think of it as ESX in the sense that you have an ESX Server hosting multiple VMs.

So,your SQL Server can host multiple DB's (instances).

The install somehow avoids any potential conflict with respect to  rollup jobs. Each install has it's own jobs and everything functions  fine.

correct.  All connections are made through ODBC and permissions on each database.  Plus, as noted all vCenter DB's have their own set of jobs

The 2nd install breaks the first DB's jobs and we'll need to manually recreate one or both sets.

This should not happen, as noted each vCenter has it's own set up jobs associated with the DB.

The 2nd DB's jobs don't get created correctly and we'll need to manually recreate one or both sets

No.  You'll only need to recreate jobs for the DB for which the jobs didn't successfully get created.

The article below will walk you through the creation of the rollup jobs if needed.  It's pretty straight forward

http://kb.vmware.com/kb/1004382

0 Kudos
vmproteau
Enthusiast
Enthusiast

Thanks Troy - I did find that KB and, despite my questions, I do understand that much about SQL. My DBA was looking through the scripts and said it looked like the install would try to create rollup jobs of the exact same name.

That's what I didn't understand. I would have assumed the install would alter the rollup job names during creation if a duplicate exists rather than just fail to create them.

0 Kudos
Troy_Clavell
Immortal
Immortal

I've attached a couple screen shots of the SQL jobs as well as our DB's.  As you can see, there are jobs for each vCenter DB (day, week, month). Hopefully this helps a bit.

0 Kudos
vmproteau
Enthusiast
Enthusiast

So did the install tag the jobs with the DB name or did you do that?

0 Kudos
Troy_Clavell
Immortal
Immortal

The install created the names.

0 Kudos
vmproteau
Enthusiast
Enthusiast

Well I guess I took us to the moon and back to get there but that's all I was making sure of :smileylaugh:. That's what I thought should happen.

Normally I would just test and see but I just joined a new company without a Lab environment and needed to be precise.

0 Kudos
Troy_Clavell
Immortal
Immortal

glad it's sorted out!

0 Kudos