Issues with 24x7 availability

I would very much like to hear from anyone out there running 24x7 with Oracle preferably on Sun Solaris. What is your service level agreement? What has your actual uptime turned out to be? What types of planned and unplanned outages have you faced? What would you do with a batch window if you had one?

We are currently running a mission critical Oracle database, but only 19 hours/day Mo-Sa, 4 hours/day Su. For a new system, we have been asked to add a requirement that the system be available 24x7. So far, nobody can provide a clear-cut business reason to do so but its so easy to write "24x7"
:-> We want to write a position paper on why they should not automatically
specify 24x7.

 Also, they have not specified in availability requirements and we're trying to find out what a reasonable availability requirements for Oracle database would be (this is an issue even if we do not have 24x7 operating hours). Despite considerable research on the Web, Usenet, several years of IOUW papers, magazines, etc. I have not been able to find anything quantitative on MTBF/MTBEs for databases, Oracle or otherwise. (Our availability over the past 12 months has been 99.91%, but we don't know if we're typical or lucky).

Our database will be an operational datastore to which nomadic clients will connect daily to upload their work and receive new assignments. We expect a peak load of 3-5 transactions (50 inserts each) per second. The database, itself, will be in the low hundreds of GB with much of that being image data. Growth is expected at 15% yearly. The database will primarily be used to exchange information among the different nomadic clients systems but will also support, at lower priority, reporting and feeds to a data warehouse.

Here are the drawbacks to announcing 24x7 availability that we have already identified:

Although Oracle has a direction to make more initialization parameters dynamically changeable, changing most database initialization parameters for tuning and turning features on and off requires a restart of the database. Also, it is sometimes desirable to run with a different initialization file during the batch window to optimize database performance for batch processing.

Periodic cold backups are desirable because they are more "foolproof" than relying entirely on hot backups.

On a 24x7 system, there is no window in which to stress test new software releases or tuning changes.

With a 24x7 system, long reports have to be run during the production window, possibly violating maximum response time agreement for online transactions. This may be mitigated by an Oracle 8i feature which allows users to be given relative priorities for resource consumption.

With a 24x7 system, there is no way to defragment a tablespace by exporting and re-importing the tablespace. (There is conflicting information on whether or not current space management in Oracle is sufficient). This might not be an issue if we partitioned the tables by date and truncated partitions as the retention period expired.

Oracle software upgrades require database to be down during upgrade. Also, time to test following the upgrade is desirable.

Any comments / experiences would be greatly appreciated.

Thanks, Deborah Received on Thu Oct 15 1998 - 14:56:26 CDT