From oracle-l-bounce@freelists.org Fri Oct 7 14:37:41 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j97JbfgB012681 for ; Fri, 7 Oct 2005 14:37:41 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j97JafvX012418 for ; Fri, 7 Oct 2005 14:36:46 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3A90C1F86D9; Fri, 7 Oct 2005 14:35:43 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31746-10; Fri, 7 Oct 2005 14:35:43 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id AD3C41F8726; Fri, 7 Oct 2005 14:35:42 -0500 (EST) X-IronPort-AV: i="3.97,188,1125896400"; d="scan'208,217"; a="35321655:sNHT22509060" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CB76.0286A342" Subject: RE: Problem with large SGA Date: Fri, 7 Oct 2005 14:33:35 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problem with large SGA Thread-Index: AcXLbH9xcPII/P4eRcqrR4bV18tblwACH+bg From: "Jesse, Rich" To: , X-OriginalArrivalTime: 07 Oct 2005 19:33:36.0435 (UTC) FILETIME=[02DA0830:01C5CB76] X-archive-position: 26577 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: Rich.Jesse@quadtechworld.com Precedence: normal Reply-To: Rich.Jesse@quadtechworld.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-mailscan-MailScanner-Information: Please contact the ISP for more information X-mailscan-MailScanner: Found to be clean X-MailScanner-From: oracle-l-bounce@freelists.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Level: X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.63 ------_=_NextPart_001_01C5CB76.0286A342 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Have you tried to trace the session that runs the ALTER? Seems like a logical place to start. =20 Rich -----Original Message----- From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of daniel.hubler@aurora.org Sent: Friday, October 07, 2005 1:24 PM To: oracle-l@freelists.org Subject: Problem with large SGA =09 =09 Oracle v8.1.7.4=20 OpenVMS 7.3-2=20 =09 We recently increased the size of our SGA from 40gig to over 100gig by increasing our shared pool and block buffer cache.=20 Everything has gone very well.=20 =09 One side effect we have encountered is that the time it takes to put all our tablespace into HOT backup=20 (ALTER TABLESPACE xxxxx BEGIN BACKUP;)=20 has gone from 1 hour to about 3.5 hours.=20 In retrospect, this makes some sense as the buffer cache is examined for blocks from the specific=20 tablespace to be written to disk; more cache to examine so it takes more time.=20 =09 Oracle has confirmed this. We have received the "expected behavior" answer regarding this issue.=20 =09 Anybody have any ideas on how to minimize the impact of this?=20 =09 =09 =09 =09 =09 =09 Dan Hubler Database Administrator Aurora Healthcare daniel.hubler@aurora.org ------_=_NextPart_001_01C5CB76.0286A342 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Have you tried to=20 trace the session that runs the ALTER?  Seems like a logical place = to=20 start.
 
Rich
-----Original Message-----
From:=20 oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] = On=20 Behalf Of daniel.hubler@aurora.org
Sent: Friday, October = 07,=20 2005 1:24 PM
To: oracle-l@freelists.org
Subject: = Problem=20 with large SGA


Oracle=20 v8.1.7.4
OpenVMS = 7.3-2=20

We recently increased the = size of our SGA=20 from 40gig to over  100gig by increasing our shared pool and = block buffer=20 cache.
Everything has gone = very=20 well.

One side effect = we have=20 encountered is that the time it takes to put all our tablespace into = HOT=20 backup
(ALTER TABLESPACE = xxxxx BEGIN=20 BACKUP;)
has gone from 1 = hour  to=20  about 3.5 hours.
In = retrospect,=20 this makes some sense as the buffer cache is examined for blocks from = the=20 specific
tablespace to be = written to=20 disk;  more cache to examine so it takes more time. =

Oracle has confirmed this.  We have = received the=20 "expected behavior"  answer regarding this issue. =

Anybody have any ideas on how to minimize = the impact of=20 this?






Dan=20 Hubler
Database Administrator
Aurora=20 = Healthcare
daniel.hubler@aurora.org
------_=_NextPart_001_01C5CB76.0286A342-- -- http://www.freelists.org/webpage/oracle-l