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-----
From: Chris Royce [mailto:Chris_at_Royce.net] Sent: Tuesday, June 13, 2000 3:51 PM
To: Multiple recipients of list ORACLE-L Subject: Data Base running too fast ???

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