Hi Eric,
SO YOU'RE THE SPAMMER! Just kidding. An increased block size is great for
read intensive applications which sounds like yours. This is because more
data can be read on each pass of the disk sector. Smaller blocks are
usually better for write intensive work.
HTH,
- Eric Fang <eric_fang_at_yahoo.com> wrote:
> Thanks, Chris, Rachel and Guy for the answers.
> Actually we don't have production database(anytime),
> so I don't even have the archive log files. My
> question is what's the benefits of increasing the
> db_block_size, what is the limit?
> I recreated a database of 16K db_block_size
> yesterday and the performance increased about 50%.
> (Our application is about sending emails to as many
> customers as possible, basically just batch
> processing).
> Thanks.
>
> Eric Fang
>
> --- Chris Royce <Chris_at_Royce.net> wrote:
> > Rachel,
> >
> > I definitely concur on the PLANNING part. I will
> > be 'resizing' our
> > Production Oracle Applications database this weekend
> > and although I am fully
> > prepared - it is still an intimidating task. Aside
> > from the obvious backups and
> > rollback procedures, I have practiced a number of
> > times and have had several
> > complete 'dress rehearsals'. There are any number of
> > 'gotchas' that cannot
> > always be anticipated. Between interdependencies,
> > cross grants, compressed
> > extents, data file size changes, SGA values that
> > change because of the block
> > size etc. etc. never mind the time it takes to do
> > the export, import, rebuild
> > indexes and then check thousands of lines of logs
> > as well as the status of your
> > objects. Then you can make sure your applications
> > still work. Not for the 'faint
> > of heart'. Also I might add - I resized our
> > development environment first and
> > had the developers thrash it around for a week
> > before I did the same in our test
> > environment - where I had a full integration process
> > take place. Absolutely
> > essential that PLANNING and preparation is observed.
> >
> > My 2 cents worth !!
> >
> > OK BYE
> >
> > Rachel Carmichael wrote:
> >
> > > well you can, sort of. Full database export, trash
> > the existing database,
> > > rebuild it with the new block size, remember to
> > adjust the init.ora
> > > parameters that will be affected by the new block
> > size, full database import
> > >
> > > But it is NOT elegant or quick. Makes a good case
> > for PLANNING before you
> > > actually build anything.
> > >
> > > Rachel
> > >
> > > >From: guy ruth hammond <grh_at_agency.com>
> > > >Reply-To: ORACLE-L_at_fatcity.com
> > > >To: Multiple recipients of list ORACLE-L
> > <ORACLE-L_at_fatcity.com>
> > > >Subject: Re: Db_block_size
> > > >Date: Thu, 08 Jun 2000 00:56:08 -0800
> > > >
> > > >Eric Fang wrote:
> > > > >
> > > > > I tried to increase the db_block_size from 8k
> > to 16k.
> > > > > What's the maximum block size allowed on NT 4
> > > > > serverice pack 5 and Soloris 2.4. Thanks.
> > > >
> > > >Eric,
> > > >
> > > >You can't change the block size after a database
> > has been created.
> > > >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos -- now, 100 FREE prints!
> http://photos.yahoo.com
> --
> Author: Eric Fang
> INET: eric_fang_at_yahoo.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
> also send the HELP command for other information (like subscribing).
Rocky Welch
Oracle DBA Consultant
rockyw_99_at_yahoo.com
Received on Thu Jun 08 2000 - 13:46:14 CDT
