Assigning two DS engines to the same xmeta repository
Moderators: chulett, rschirm, roy
Assigning two DS engines to the same xmeta repository
Hi guys
Want to know if anyone has experience in using the same metadata repository for two (or more) DS Engines.
That is when you install the second engine, then you should be able to select an already existing db instance to work as repository for jobs running the second engine also, eliminating the option to run create_tables.sql etc.
If this is not possible, then a brief explanation of why not??
Searched all over, but apparently there is no ocument anywhere describing this setup (did however find a drawing at the publib site from IBM
Want to know if anyone has experience in using the same metadata repository for two (or more) DS Engines.
That is when you install the second engine, then you should be able to select an already existing db instance to work as repository for jobs running the second engine also, eliminating the option to run create_tables.sql etc.
If this is not possible, then a brief explanation of why not??
Searched all over, but apparently there is no ocument anywhere describing this setup (did however find a drawing at the publib site from IBM
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
That's the way it's intended to work. The last two sites I've installed have five and two engines respectively. You install selecting Engine tier only, and are then asked for the location (and other information) for the Services tier.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 527
- Joined: Thu Apr 19, 2007 1:25 am
- Location: Melbourne
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Planning, Installation and Configuration Guide version 8.7 page 22 Figure 14 - Topology with Two Engine Tiers
For "two" read any reasonable number of Engine tiers.
For "two" read any reasonable number of Engine tiers.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
The engines can register to the same services tier, and would store their respective metadata within the same repository database. Only shared metadata, as defined by Information Server (shared table definitions, etc.) can be accessed by both engines, but they would NOT share jobs and other engine-specific objects.
Regards,
Regards,
- james wiles
All generalizations are false, including this one - Mark Twain.
All generalizations are false, including this one - Mark Twain.
Thanks a ot for the effort guys.
"but they would NOT share jobs and other engine-specific object" - which is my problem.
I think we will go with a solution to have two repositories, located in the same physicla database under different schema owners.
Oracle will than be able to handle high availability on the repository
BR Jan
"but they would NOT share jobs and other engine-specific object" - which is my problem.
I think we will go with a solution to have two repositories, located in the same physicla database under different schema owners.
Oracle will than be able to handle high availability on the repository
BR Jan
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
That "solution" will still not share jobs and other engine-specific objects.
Information Server does have built-in HA capability in the services and repository tiers, but there's no way to get running jobs or connected client sessions to fail over.
Information Server does have built-in HA capability in the services and repository tiers, but there's no way to get running jobs or connected client sessions to fail over.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Premium Member
- Posts: 730
- Joined: Tue Nov 04, 2008 10:14 am
- Location: Bangalore
Issue is all about saving money - Running one Oracle database costs x thousand euros a year.
My idea was that if fail over engine and services could use the same Oracle repository and leave the Oracle part of the failover to say Data Guard, than a pretty amount of money could be saved.
Instead we now use different schemas in the same Oracle Instance for the two sets of engine/services, and then save the license fees in that way.
Automatic failover of running jobs etc is not something we request or desire
My idea was that if fail over engine and services could use the same Oracle repository and leave the Oracle part of the failover to say Data Guard, than a pretty amount of money could be saved.
Instead we now use different schemas in the same Oracle Instance for the two sets of engine/services, and then save the license fees in that way.
Automatic failover of running jobs etc is not something we request or desire