installing multiple databases on one host
Remigiusz Boguszewicz
I am standing right now before a task to install many databases on one
host. I know this is waste of resources and that all shoul be put to one
instance and managed with different schemas - but please just leave the
discussion asaid.
I see three choises.
1. One Binary. Many databases. One oracle user to rule them all.
- I change current database by changing ORACLE_SID
- patch has to be applied against only one ORACLE_HOME, eventualy
scripts has to be run on each database
- patching is relatively simple, but with the risk that all databases
will be out of service if something goes wrong
2. Multiple binaries. Each database - instance has its own oracle
binary. One oracle user to rule them all.
- I have to change ORACLE_SID and ORACLE_HOME to switch between databases
- patch has to be applied against each ORACLE_HOME, eventualy scripts
has to be run on each database
- patching is a bit more involving but I gain the ability to patch less
critical databases and wait a while.
3. Multiple binaries. Each database - instance has its own oracle
binary. Multiple users - each one is controling its own database.
- even more 'secure' than 2. Each user has its own account, its own
.profile so I always know on what database I am, can not mess with
others databases. Every user has to launch its own listener thus on
different ports.
- as far as I know all database users has to share common group to
access oracle inventory. I do not like the idea, because total
separation of all databases would be nice, but well - what to do?
- patching as in 2.
Personaly I like nr 3. but till now was working with 1. Are there any
gotchas? What with the inventory? What If I want to restore database on
different host (in scenario 3.) - I need all that belongs to a certain
user and? Inventory?
Please comment. Perhaps there is more elegant, better approach to
stuffing many databases on one host.
Greetings
Remigiusz Boguszewicz
Steve
My vote's for 1. Less admin overhead -> easy life -> good idea(tm) If
your hardware fails, then you'll have them all out of commission anyway.
And that's for a *nix or M$ solution,too.
Steve
Remigiusz Boguszewicz
> My vote's for 1. Less admin overhead -> easy life -> good idea(tm) If
> your hardware fails, then you'll have them all out of commission anyway.
>
> And that's for a *nix or M$ solution,too.
>
> Steve
Hi Steve,
thanks for a comment.
That is for *nix. With a lot of RAM and hdd space.
I am already experimenting with scenario 3.
Other Pros I have noticed:
+ I can temporary disable selected database from outside world by
removing tnsnames.ora, which is impossible with scenario 1.
+ More and more I like the idea of many users, with man .profile files
Cons:
- I still do not know if I need a common dba group. At first I have
tried with different one but to no avail. (I got "ORA-01031:
insufficient privileges" after sqlplus "/ as sysdba")
Greetings
Remigiusz Boguszewicz
Remigiusz Boguszewicz
> your hardware fails, then you'll have them all out of commission anyway.
Some other thoughts:
- I do not worry about hardware failure but patches hell. Want to test a
patch on some databases before going with it to others.
Hans Forbrich
> Hi,
>
> I am standing right now before a task to install many databases on one
> host. I know this is waste of resources and that all shoul be put to one
> instance and managed with different schemas - but please just leave the
> discussion asaid.
>
Binaries = ORACLE_HOME ...
I look at an ORACLE_HOME as being the unit of software patching & upgrading
maintenance.
If your instances need to be patched and upgraded separately, (different
test cycles, different service agreements, different user community
demands) then use separate Oracle Homes.
If you need to be able to hold an instance back on an old release (eg:
vendor application) - separate ORACLE_HOME
The big advantage to separate INVENTORY is that a test environment can be
totaly blown away in one 'rm -r'. Otherwise removal deletes the inventory
items - one at a time. But - since the inventory is MY database, I'd
prefer to have one, not many.
/Hans
Remigiusz Boguszewicz
> If your instances need to be patched and upgraded separately, (different
> test cycles, different service agreements, different user community
> demands) then use separate Oracle Homes.
>
> If you need to be able to hold an instance back on an old release (eg:
> vendor application) - separate ORACLE_HOME
YES - this exactly what I want
> The big advantage to separate INVENTORY is that a test environment can be
> totaly blown away in one 'rm -r'. Otherwise removal deletes the inventory
> items - one at a time. But - since the inventory is MY database, I'd
> prefer to have one, not many.
Please clarify. Is it possible to have multiple Inventories?
What do you mean by:
> But - since the inventory is MY database, I'd
> prefer to have one, not many.
Remigiusz
Jim Kennedy
"Remigiusz Boguszewicz" <zebr...@poczta.onet.pl> wrote in message
news:cjgpde$5a7$1...@news.onet.pl...
I'd go with one except have separate environments (oracle homes) for
different levels of service. We have development, test, and production.
Test and Dev reside on the same box and could have different
binaries.(currently they do not, but on a major upgrade from Oracle they
are.) So work and changes go from development to test to production. (after
testing at each step)
Jim
Steve
>
>> My vote's for 1. Less admin overhead -> easy life -> good idea(tm) If
>> your hardware fails, then you'll have them all out of commission anyway.
>>
>> And that's for a *nix or M$ solution,too.
>>
>> Steve
>
>
> Hi Steve,
>
> thanks for a comment.
> That is for *nix. With a lot of RAM and hdd space.
> I am already experimenting with scenario 3.
> Other Pros I have noticed:
> + I can temporary disable selected database from outside world by
> removing tnsnames.ora, which is impossible with scenario 1.
[sni[p]
Bruno Jargot
> Other Pros I have noticed:
> + I can temporary disable selected database from outside world by
> removing tnsnames.ora, which is impossible with scenario 1.
It's not a valid argument. You can use the TNS_ADMIN variable if you
want to have several tnsnames.ora
> + More and more I like the idea of many users, with man .profile files
I don't think it's a valid argument. You should install the Oracle
binaries with a dedicated user (used only for the install). And you
should this user only for the installation of patch. So having several
.profiles files is, IMHO, useless.
> Cons:
> - I still do not know if I need a common dba group. At first I have
> tried with different one but to no avail. (I got "ORA-01031:
> insufficient privileges" after sqlplus "/ as sysdba")
You choose the group which will give you the "privilege" when you
install the binaries. If you have several installation, you can have
several dba group.
And I think that's the main Pro for having several installation :
Each instance will use a different user for running the background
processes. As the oracle binary has a setuid bit, the user executing the
database processes is the user used for the installation of the binaries
(and not the one which has launched the database). So the database will
be completely independant each other. Having different user will allow
to identify easily which database use which resource. Instead of having
several shared memory owned by only one user (and not being able to know
which instance own which shared memory segment), you will immediately
know, by the owner of the segment, the associated instance.
So, if you have enough disk (for the several binaries installation) and
enough RAM (the processes will not share readonly memory segment between
the instance), so yes, I think it can be a good idea to have several
binaries.
Hans Forbrich
>
> Please clarify. Is it possible to have multiple Inventories?
> What do you mean by:
First time you install (ever) on a machine, Oracle asks for the directory to
keep the Oracle Universal Installer related information, including the
inventory of software Oracle has installed. This is known as the
'inventory location'
On *nix machines you can create multiple inventory locations. Look in
Metalink for the information about how. Wile possible, I don't think it's
worth while under normal situations. One possible reason fr doing so is:
you plan on creating and discarding complete install-from-disk cycles.
/Hans