Re: major blunders

  • From: Mayen.Shah@xxxxxxxxxx
  • To: frits.hoogland@xxxxxxxxx
  • Date: Wed, 7 Oct 2009 14:50:01 -0400

Not testing recovery scenarios is also one of the major blunders.

Testing recovery is as important as taking regular backups.

Mayen






"Frits Hoogland" <frits.hoogland@xxxxxxxxx> 
Sent by: oracle-l-bounce@xxxxxxxxxxxxx
Oct 07 2009 02:44 PM
Please respond to
frits.hoogland@xxxxxxxxx


To
jifjif@xxxxxxxxx
cc
"Oracle-L@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
Subject
Re: major blunders


in the line of not having a backup:

having the database backup done by another team than the DBA's, and doing 
it hot with putting tablespaces into backup mode, which is done by logging 
on to the database with the SYSTEM account. this on itself works, but 
fails if all database passwords needs to be changed, and the backup script 
isn't altered (of course there is a hardcoded password in it), because it 
isn't in control of the DBA team.

looks outdated, but still occuring:

outsourcing to india because of cost, and thinking it all "magically" goes 
well.

something all performance consultants will have encountered:

clients/programmers who believe: parallel improves performance, increasing 
parallelism improves performance even more, and increasing parallelism 
even more will improve performance once again. seen it been bumped up to 
48 slaves for a single table with 4 CPU's and locally attached disks. 






On Wed, Oct 7, 2009 at 8:26 PM, ~Jeff~ <jifjif@xxxxxxxxx> wrote:
here's a couple of biggies that havent been mentioned yet:
- not having a backup   !!!!
- letting the newby DBA loose in production (see previous point!)

cheers-
Jeff

2009/10/8 April Sims <sims@xxxxxxx>

Compiling a list of major blunders to avoid:

Don't use the number 8 for scripting or ORACLE_SID due to the wild card 
character * above it.
Don't use rm *.*
....

Anyone else have some to contribute?

thanks


April Sims
SELECT IOUG Contributing Editor
http://aprilcsims.wordpress.com
OCP 8i, 9i, 10g DBA
Southern Utah University
sims@xxxxxxx
940-484-4276


--
//www.freelists.org/webpage/oracle-l




Other related posts: