RE: Data Base running too fast ???

Heck why stop there. Move your redo and archive logs, control file, indexes ...
to the same disk also. Reduce your SGA until you start swapping to disk. Reduce your DB block size to a fraction of the OS size.

Either that or port it over to NT (just kidding I'm on NT).

-
Chris J. Guidry P.Eng.
ATCO Electric, Metering Services
Phone: (780) 420-4142
Fax: (780) 420-3854
Email: chris.guidry_at_atcoelectric.com

> -----Original Message-----
> From: Gogala, Mladen [SMTP:MGogala_at_oxhp.com]
> Sent: Tuesday, June 13, 2000 3:14 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Data Base running too fast ???
>
> You can decrease shared pool to the point that rowcache shows hit rates
> of around 50%, decrease sort_area_size to 5k (make sure it's relatively
> prime
> to your page size and initial extent size), move your temporary, rollback,
> users
> and system tablespace to the same disk, drop few indexes and unkeep few
> procedures
> and packages and everything will be much better. Don't forget to use MTS
> without
> CMAN and to make your tablespace system temporary tablespace for all
> users.
> You should
> also turn on ANSI-standard locking and I guarantee that your database will
> not be
> caught speeding ever again.
>
> -----Original Message-----
> Sent: Tuesday, June 13, 2000 3:51 PM
> To: Multiple recipients of list ORACLE-L
>
>
> Anyone had problems with a database running too fast. It was a first for
> me. I recently, upon gaining additional disk and memory, was able to
> re-archetect several of my production instances. I also tuned the heck
> out of them and optimized to the maximum that our physical configuration
> would allow.
>
> One of our 'canned' applications captures employee clock punches at our
> manufacturing plants and sends them to an Oracle database where they are
> processed before going to our HR application. Shortly after the database
> re-org we started encountering duplicate records in a transaction table
> (no unique key constraint). The application Vendor spent a bunch of time
> debugging the problem and it was discovered that the clock punches are
> captured only down to the second and as a result the processing speed of
> our system allows duplicate records when multiple punches are captured.
> Prior to the reorganization this had not been an issue. The Vendor
> complained that the database was too fast !!! Sometimes you can't win.
> We declined to 'slow down' the database and suggested that the onus be
> on them to refine the degree of granularity that the time records are
> captured.
>
> Much better situation than some of the incredibly interesting disaster
> stories that have appeared lately.
>
> Chris Royce
> Jamestown NC
>
> --
> Author: Chris Royce
> INET: Chris_at_Royce.net
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
> --
> Author: Gogala, Mladen
> INET: MGogala_at_oxhp.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
Received on Tue Jun 13 2000 - 17:38:46 CDT