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.
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.
The install created the names.
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.
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?
rollup jobs are associated with vCenter DB instances only. Each vCenter DB instance has it's on set of jobs.
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:
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.
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
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.
So did the install tag the jobs with the DB name or did you do that?
The install created the names.
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.
glad it's sorted out!