RE: major blunders

From: Aragon, Gabriel (GE, Corporate, consultant) <"Aragon,>
Date: Wed, 7 Oct 2009 15:03:47 -0400
Message-ID: <5409709395C6884598ADE701EDED9ACDA1A8AC_at_CINMLVEM17.e2k.ad.ge.com>



Do not execute huge scripts at once, or without verifying content, most of all for scripts generated by tools like TOAD. A newbie DBA generated a script using TOAD and didn't uncheck "Drop table" option. Script was executed in production.  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Toon Koppelaars Sent: Miércoles, 07 de Octubre de 2009 01:53 p.m. To: Mayen.Shah_at_lazard.com
Cc: frits.hoogland_at_gmail.com; jifjif_at_gmail.com; Oracle-L_at_freelists.org; oracle-l-bounce_at_freelists.org Subject: Re: major blunders

Absolutely right.

They should strike the term "backup strategy" all together from the documentation.

It's "recovery strategy" that's important. How to backup is a derivative from that.

On Wed, Oct 7, 2009 at 8:50 PM, <Mayen.Shah_at_lazard.com> wrote:

        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_at_gmail.com>
Sent by: oracle-l-bounce_at_freelists.org

Oct 07 2009 02:44 PM

Please respond to
frits.hoogland_at_gmail.com

To
jifjif_at_gmail.com
cc
"Oracle-L_at_freelists.org" <oracle-l_at_freelists.org>
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_at_gmail.com <mailto:jifjif_at_gmail.com> > 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_at_suu.edu <mailto:sims_at_suu.edu> > 
	
	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 <http://aprilcsims.wordpress.com/> 
	OCP 8i, 9i, 10g DBA
	Southern Utah University
	sims_at_suu.edu <mailto:sims_at_suu.edu> 
	940-484-4276
	
	
	--
	http://www.freelists.org/webpage/oracle-l <http://www.freelists.org/webpage/oracle-l> 
	
	
	
	
	




-- 
Toon Koppelaars
RuleGen BV
+31-615907269
Toon.Koppelaars_at_RuleGen.com
www.RuleGen.com
TheHelsinkiDeclaration.blogspot.com

(co)Author: "Applied Mathematics for Database Professionals"
www.RuleGen.com/pls/apex/f?p=14265:13



--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 07 2009 - 14:03:47 CDT

Original text of this message