To replicate the data , they may to make some changes in the application
which is third party written and they don't want to change the code.
So the feasible and easiest solution looks like maintaining a standby
database
and switching it between standby and read mode when needed.
-----Original Message-----
From: Ashish Shah [mailto:ar_shah_at_yahoo.com]
Sent: Tuesday, June 20, 2000 12:21 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Block size or replication?
I suggest you should go with replication. We do
it here and it works like a charm..
Ashish
- "Singla, Sanjeev" <SSingla_at_oxhp.com> wrote:
> If u increase the block size and u are using Oracle
> parallel server then
> there can be
> potential issues of pinging the blocks accross
> nodes. Because with one block
> read into the
> SGA there will be more records locked by the
> instance. There can be
> potential concurrency
> and performance issues. But if u are single instance
> Oracle and u are
> running mixed jobs
> (OLTP+Batch( then u can be better off with
> increasing the block size))
> Another solution is to maitain a standby database
> (provided u r in Oracle
> 8.x) which will automatically
> get refershed with the archive logs and whenever u
> want u can open it for
> batch (read only jobs).
> But keep in mind to create ur temporary tablespace
> as locally managed.
> Because dictionary will be
> in read only mode and ur reporting may need some
> temp sorts.
>
> Cheers
> Sanjeev
>
> -----Original Message-----
> Sent: Tuesday, June 20, 2000 11:07 AM
> To: Multiple recipients of list ORACLE-L
>
>
> We have an OLTP system that has frequent long
> running Crystal Reports
> reports that affect the overall online performance.
> We are looking at ways
> to improve response time. This is a purchased app
> and we do not modify
> code. We are looking at doing replication to
> offload some of the
> processing. But I am wondering if increasing the
> blocksize would be a
> better solution. The ad-hoc reports often do full
> table scans, as do the
> OLTP programs. This is even though there are
> indexes available. Remember
> we don't change code. The current block size is
> 4096. I would like to
> change it to 8192. I am thinking this would cut
> full table scan i/o in half
> and speed up processing. Any ideas?
>
> Ron Smith
> Database Administration
> rlsmith_at_kmg.com
>
>
> --
> Author: Smith, Ron L.
> INET: rlsmith_at_kmg.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).
> --
> Author: Singla, Sanjeev
> INET: SSingla_at_oxhp.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).
Ashish
Toronto, Canada
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/
--
Author: Ashish Shah
INET: ar_shah_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
Received on Tue Jun 20 2000 - 11:06:29 CDT
