Re: Issues with 24x7 availability

Hi Deborah,

I too hate it when users specify 24x7 without knowing what it means. However, my $0.02 worth!

> 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.

24x7 and *huge* databases don't go hand in hand. Consider the possibility of separating essential and non-essential stuff. Why? If disaster strikes, you will have to clear a smaller mess! If you haven't considered an Oracle 8 partitioned database, then you should... partitioning will help in managing the big 'uns.

> 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.

I read in Oracle8 Concepts Manual that it is possible with the O8 Parallel Option to be able to specify a single connect string and have user failover from one instance to another when you bounce each of them. Worth reading up on that..

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

Yes, but if you manage to implement bullet-proof backup (and RECOVERY!!) procedures, and *TEST* recovery for various scenarios, and generally ensure that changes are controlled and documented, you can rely on hot backups. Most apprehensions arise in this area due to lack of knowledge and procedures - the manuals are certainly not helpful here!

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

Yes - One of the major problems, but I would then use the customer's requirements (for 24x7) to buy a scaled down test server along with the committment to participation in pilot projects before actual rollout. I always say that 80% of the $$s are spent in achieving the last 20% of the functionality!

>
> 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.

Huh! haven't heard of this feature?!

> 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.

Correct.

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

Yes - but you could also follow a cutover-cutback using a backup server (goes back to my previous statement - need big $$). This will be easily facilitated by using a central storage system such as EMC or the newly announced Seascape technology from IBM.

FYI, I am one of two lead DBAs/Sys Admins managing about 55 Oracle instances across a variety of platforms on which we run about 200 local/third party applications many of which are constantly undergoing upgrades. So far, we don't have a 24x7 requirement yet, but expect it to happen soon...

Hope this helps,
John Kanagaraj
Brunei Shell Petroleum

-----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own Received on Sat Oct 17 1998 - 03:35:47 CDT