Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: DBA Information question...

Re: DBA Information question...

From: Joachim Ring <jring_at_gmx.de>
Date: Wed, 17 Apr 2002 23:27:32 +0200
Message-ID: <a9kp3m$40qa5$1@ID-28434.news.dfncis.de>


> I would suggest that you supply your customers with an initSID.ora and
a series
> of build scripts (starting with create database, followed by creation
of temp,
> rollback, data, and index tablespaces, etc.). Add instructions on
which
> parameters they can modify and which they can not. And what
considerations
> relate to how it is modified.
>
> I've done this for more than a few customers. And every time they are
left to
> create their own my clients have ended up sending in support personnel
to clean
> up the mess. Seemingly small things like block size and character set
can make a
> huge difference.

while i heartily agree with the latter sentence i'd always prefer good guidelines on how to build the instance over pre-cooked scripts only.

i was involved in getting to run a finance app from a well known company which shall go unnamed here, where the whole database creation went scripted. not only did those grant dba with admin option to the only technical account created (app has it's own account handling) without any need but the tablespace layout and sizing made our dba cry on first sight. no wonder that the application was crawling despite running on a large sunfire box. the support personnel wasn't much use either (they were more accustomed to seeing their app run on windoze and on a much smaller scale).
so the dba and me spent quite some time analyzing bottlenecks and she did a great tuning job decreasing access time over two orders of magnitude by rearranging tablespace layout, changing block- and extent-sizes and telling me which stored procedures in the app deserved a once-over.

so there was happiness - until the next release...

as it happened, the upgrade process was wholly scripted too - unfortunatly it involved dropping and recreating about 99% of some hundreds of tables and indexes and alas, recreating them with the same stupid tablespace layout and sizing as originally - all was hardcoded :-(
to make things worse it was not one or a few scripts to change but tables and indexes were dropped and created as needed in the big bunch of scripts updating the stored procedures & packages, so each new revision takes me some long days to adapt the scripts not f*** everything up again...

no, i'd always prefer good documentation to precooked scripts. maybe scripts for those without a good dba and docs for everybody else...

joachim Received on Wed Apr 17 2002 - 16:27:32 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US