The community will be in read-only from Tuesday 11:59pm (PST) to Wednesday 7:30am (PST)
The community will be in read-only from Tuesday 11:59pm (PST) to Wednesday 7:30am (PST)
Service Desk Practitioners Forum
cancel
Showing results for 
Search instead for 
Did you mean: 

SD Consolidated Database

Highlighted
Sharon F. Santi
Collector

SD Consolidated Database

To SD Gurus,

Is it possible to consolidate the databases used by Service Desk? Can an application server use different databases?

A client, has 3 sites (A,B,C) and they would want a separate database per site to be used by SD. In my understanding, an application server uses one particular database..so, if in this case, each site will require 3 application servers. However, they would want the main site (A) to be able to view the service calls within site B & C and just let site B & C have access on there own db. Is this possible?

At first, I was thinking of just having a centralized db and just enable folder entitlement to define the rights for each site. But then, they would insist on having separate db for the 3 sites.

Need advise. Thanks

Sharon
4 REPLIES
Robert S. Falko
Honored Contributor

Re: SD Consolidated Database

Sharon,

If separate databases is a must have requirement, then there may have been an error in selecting OVSD as the solution. Is it really a non-negotiable requirement?

Here's what you can do if you really must have separate databases...
1) Use ACES (and ONLY ACES) to make sure that all databases have identical reference data.
2) Use DataExchange to extract data from the source databases and then import them into a consolidated database. If you have any differences at all in the reference data (and I mean down to the OID for each row, which is why you MUST use ACES), then this will fail. If you have any logic based on the IDs of objects, then this will fail.


Here's what you can do to create logical partitions in a single database...
1) Create a folder for each site.
2) Assign the transactional data for each site to its own folder.
That sounds a lot simpler to me. Plus, consolidated reporting is no longer a nightmare.

Good night and good luck,
-Josh
Victor Helsinki
Super Collector

Re: SD Consolidated Database

Hello Sharon

Firstly, as far as I know, there is no way a series of application servers can use multiple databases.

To seperate sites A,B and C, you need to run seperate instances of Service Desk (Using different databases). But if you make them work together, you can't use different databases. Here are two recent Service Desk exam questions, and answers related to your situation:

Q:What are four consequences of using multiple application servers in a single Service Desk environment?

Correct Answers Are:
+ Availability of a failover system
+ Ability to use load-balancing
+ Ability to use multiple operating systems
+ Ability to run data-exchange processes on a seperate server

Wrong Answers;
-Ability to use Service Desk 4-tier architecture
-Ability to use multiple databases

Q:
Also bear in mind that 'With multiple application servers, when an application server goes down, the clients connected to that application server will automatically reconnect to another application server'

Also here is some documentation about multiple application servers and multiple databases.

http://openview.hp.com/sso/ecare/getsupportdoc?docid=OV-EN010565
Sharon F. Santi
Collector

Re: SD Consolidated Database

Hi Josh and Victor,

We're just about to do a POC in the client and this is one of the requirements. I already had an idea that this may not be possible, still i wanted to get experts opinion

I guess using the ACES for import of identical data would be another discussion with the client. This may sound tedious for them and requires so much of administration among the three sites.

Points well taken, il have this during the discussion with the client.Thank you for taking time to reply. Such an immediate response, I appreciated it.

Regards,
Sharon




FRANS_5
Collector

Re: SD Consolidated Database

Sharon,
You could achieve the desired result by having Oracle replication copy (vv) the two federated CMDBs into the main one. Access can be managed using folders and permissions (roles).

Still, what I do not understand: why is having a single CMDB, with domains separated by folders, not an option?

Whatever you do, the solution has to be a logical single instance, or you might get clashing OIDs/UUIDs.

Frans
The early worm gets the bird.
//Add this to "OnDomLoad" event