: If the server capacity and network capacity are properly assessed, it
: causes no problems. The only potential issue outside of capacity is
: availability schedules for backup and recovery. Under one instance, if
: one app DB is corrupted, all of them are taken off-line for recovery in
: some cases. Cold backups require all apps being off-line at the same
: time for the entire backup process, which, I imagine, is now much
: longer.
Add to that list :
- Upgrading the OS or DB version for one instance or application could
impact the others, which could cause compatability problems (upgrading the
OS and RDBMS may mean that some legacy code or application will break in
some way - we have an application that must use SQL*Net V1, which limits our
choice of RDBMS)
- Name resolution issues could become important if within one instance (public
synonyms could become a major pain if several apps all have tables with the
same name);
- Security implications if within one instance (users of one app seeing,
accessing the data in another, etc).
- If you are now running client-server instead of having the application
software on the same machine as the db you should double-check the network
capacity and also security - are there any requirements for encryption ?
Also how are the users connecting to the db - if it's via OPS$ accounts, is
this really a good idea across a network ?
- Double check that the such things as capacity and speed of backup media
to ensure that backups can be done in a timely fashion
- Think carefully if you are going to have one instance for all apps or one
per application.
- Build extra growth capacity into the design of the super-server. Have spare
partitions available such that you can allocate them to tablespaces in an
emergency, etc.
- Maybe look at mirroring of disks, etc.
IAP
--
In an attempt to reduce junk email I use an invalid 'From' address.
My my correct email address can be be determined by replacing 'not.valid' with
'value.net'
Received on Tue Sep 16 1997 - 00:00:00 CDT
