OSDI subsystems [message #113661] |
Fri, 13 April 2001 07:30 |
Dean Saunders
Messages: 11 Registered: April 2001
|
Junior Member |
|
|
In the Oracle SIG presentation by Jim Gillesppie, he recommended that there should be one OSDI per LPAR with one OSDI parmlib dataset and one LINKLIB dataset. Below is the OSDI subsystem example that
that I will code in "SYS1.PARMLIB(IEFSSNZS)".
SUBSYS SUBNAME(OSDI)
INTRTN(ORASSINI)
INITPARM('ORACLED.ORA.PARMLIB(OSDIPARM)')
However if I need to have multiple versions of the database services and Net8 services in one LPAR, then I will need to have multiple subsystems to keep these services at different versions or releases. This really
defeats the purpose of reducing the number of subsystems in an OSDI Oracle architecture. Do you have any suggestions for me to get around this situation? or will I need to have multiple subsystems anyway?
Thanks for your help
Dean Saunders
United Space Alliance
|
|
|
Re: OSDI subsystems [message #113662 is a reply to message #113661] |
Mon, 16 April 2001 03:01 |
Pat Mason
Messages: 11 Registered: July 2000
|
Junior Member |
|
|
: However if I need to have multiple versions of the database services and Net8 services in one LPAR, then I will need to have multiple subsystems to keep these services at different versions or releases.
: Dean Saunders
: United Space Alliance
Dean,
When you say multiple versions, are you referring to the software versions (ie. 8.1.7) or are you referring to multiple instances?
|
|
|
Re: OSDI subsystems [message #113663 is a reply to message #113662] |
Mon, 16 April 2001 06:38 |
Dean Saunders
Messages: 11 Registered: April 2001
|
Junior Member |
|
|
: : However if I need to have multiple versions of the database services and Net8 services in one LPAR, then I will need to have multiple subsystems to keep these services at different versions or releases.
: : Dean Saunders
: : United Space Alliance
:
: Dean,
: When you say multiple versions, are you referring to the software versions (ie. 8.1.7) or are you referring to multiple instances?
I refer to multiple instances with each instance
at a different release level, for example we could
have releases 8.1.7, 8.1.8 or 8.1.9 at the same
time in one LPAR. tHE ORASSINI and other modules in the LINKLIB may be different. There is no
guarantee that these modules will not change
with each new release upgrade. If that is the
case, we may have to have multiple subsystems
in order to keep each instance separated.
Dean
|
|
|
Re: OSDI subsystems [message #113664 is a reply to message #113663] |
Tue, 17 April 2001 04:20 |
Pat Mason
Messages: 11 Registered: July 2000
|
Junior Member |
|
|
Good question. I don't have the answer myself but will watch this thread to find out more.
My best guess would be that databases instances with the same release could all be under the same OSDI subsystem but would need a seperate OSDI subsystem for software version.
|
|
|
Re: OSDI subsystems [message #113666 is a reply to message #113664] |
Tue, 17 April 2001 12:35 |
Dean Saunders
Messages: 11 Registered: April 2001
|
Junior Member |
|
|
: Good question. I don't have the answer myself but will watch this thread to find out more.
: My best guess would be that databases instances with the same release could all be under the same OSDI subsystem but would need a seperate OSDI subsystem for software version.
:
That is a good guess Pat, because Jim Gillespie
recommended in an email to me that I should have
multiple OSDI subsystems to keep different Oracle releases separated.
Dean
subsystems
|
|
|
Re: OSDI subsystems [message #113724 is a reply to message #113666] |
Wed, 05 September 2001 09:36 |
brad simmons
Messages: 7 Registered: September 2001
|
Junior Member |
|
|
You can only have 1 oracle subsystem (OSDI) active per LPAR. Oracle says they're working so the most recent OSDI subsystem code is backward compatible with previous releases of the database services.
So you might have the 8.1.7.3 OSDI code running with services for multiple versions (8.1.7.x) of your various databases.
Of course, TESTING a new OSDI version is tricky -- if you don't want to affect existing systems, you'll need a new LPAR....
...hmmmm.
|
|
|