Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 9118 invoked from network); 18 Sep 2007 23:06:29 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 18 Sep 2007 23:06:29 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 20E7875CFBD; Wed, 19 Sep 2007 00:06:29 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15392-04; Wed, 19 Sep 2007 00:06:29 -0400 (EDT) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 8C05B75CFAA; Wed, 19 Sep 2007 00:06:28 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 18 Sep 2007 23:20:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6679775C3B6 for ; Tue, 18 Sep 2007 23:20:59 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11304-04 for ; Tue, 18 Sep 2007 23:20:59 -0400 (EDT) Received: from smtp101.plus.mail.sp1.yahoo.com (smtp101.plus.mail.sp1.yahoo.com [69.147.95.64]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with SMTP id 29EE275D4A5 for ; Tue, 18 Sep 2007 23:20:37 -0400 (EDT) Received: (qmail 2181 invoked from network); 19 Sep 2007 02:33:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:In-Reply-To:Importance:X-MimeOLE; b=JRJu1cEH74LeQq14cRtj0LyAE9LvKspeqdjK/hR+yllV50VaqSG9A5qLU8d3N5xH4SCltW36CYb2vJEvC5ww4UMH0lrIzXDINizdIYRjtm64ulTmEb5xDV5/d4X4baLi2WcZnDFUZe9kqWKwxTBSgTbCsSaMJCLHrALn9Epp8T8= ; Received: from unknown (HELO robertssony) (robertgfreeman@76.27.76.240 with login) by smtp101.plus.mail.sp1.yahoo.com with SMTP; 19 Sep 2007 02:33:15 -0000 X-YMail-OSG: vb79VqMVM1kyj4zeZt4ILfJv840ts10llYIFY78UnoKBAHvHrI4izyBA2LKwqCKWr05L43AT_uHghF_axD.kt8zprO_dQq7YxJ05atg7Dqja8KWJQQ-- From: "Robert Freeman" To: , Subject: RE: rman allocate channel suddenly taking forever Date: Tue, 18 Sep 2007 20:34:05 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A6_01C7FA33.416B5DE0" In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-archive-position: 1675 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: robertgfreeman@yahoo.com Precedence: normal Reply-to: robertgfreeman@yahoo.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: Debian amavisd-new at localhost.localdomain ------=_NextPart_000_00A6_01C7FA33.416B5DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit We are having some major performance problems with our recovery catalogs these days!! Contact Oracle and open an SR, there are several bugs open with catalog performance and degrading performance. RF Robert G. Freeman Oracle Consultant/DBA/Author Principal Engineer/Team Manager The Church of Jesus Christ of Latter-Day Saints Father of Five, Husband of One, Author of various geeky computer titles from Osborne/McGraw Hill (Oracle Press) Oracle Database 11g New Features Now Available for Pre-sales on Amazon.com! BLOG: http://robertgfreeman.blogspot.com/ Sig V1.2 -----Original Message----- From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org]On Behalf Of Gerald Cunningham Sent: Tuesday, September 18, 2007 12:50 PM To: oracle-l@freelists.org Subject: rman allocate channel suddenly taking forever Hi all, We run an rman level 0 backup of a Dataguard physical target database, twice a week, to disk. The first thing the job does is allocate 10 disk channels. This part of the job (the allocate commands) usually takes 40 minutes to a little over an hour. For the last 3 runs of this backup job, however, the allocate is taking over 9 hours. I should note that this is a very large database with 10's of thousands of data files. This is Oracle 9.2.0.7 64-bit on Solaris. Any suggestions as to what we might look at? What exactly happens internally during the allocate channel command? My rman catalog db is generating 3.1 Gb or archive logs during the 9 hours that the allocate channel commands are running. Thanks for any help or pointers... we've searched Metalink but came up with nothing. Jerry ------=_NextPart_000_00A6_01C7FA33.416B5DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We are=20 having some major performance problems with our recovery catalogs these=20 days!!
Contact Oracle and open an SR, there are several bugs open with = catalog=20 performance and degrading performance.

RF
 

Robert G. Freeman
Oracle = Consultant/DBA/Author
Principal=20 Engineer/Team Manager
The Church of Jesus Christ of Latter-Day=20 Saints
Father of Five, Husband of One,
Author of various geeky = computer=20 titles
from Osborne/McGraw Hill (Oracle Press)
Oracle Database 11g = New=20 Features Now Available for Pre-sales on Amazon.com!
BLOG: http://robertgfreeman.blogspot.com/
Sig = V1.2

-----Original Message-----
From:=20 oracle-l-bounce@freelists.org = [mailto:oracle-l-bounce@freelists.org]On=20 Behalf Of Gerald Cunningham
Sent: Tuesday, September 18, = 2007=20 12:50 PM
To: oracle-l@freelists.org
Subject: rman = allocate=20 channel suddenly taking forever

Hi all,
 
We run an rman level 0 backup of a = Dataguard=20 physical target database, twice a week, to disk. The first thing the = job does=20 is allocate 10 disk channels. This part of the job (the allocate = commands)=20 usually takes 40 minutes to a little over an hour. For the last 3 runs = of this=20 backup job, however, the allocate is taking over 9 hours.
 
I should note that this is a very = large database=20 with 10's of thousands of data files. This is Oracle 9.2.0.7 64-bit on = Solaris.
 
Any suggestions as to what we might = look at? What=20 exactly happens internally during the allocate channel command? My = rman=20 catalog db is generating 3.1 Gb or archive logs during the 9 hours = that the=20 allocate channel commands are running.
 
Thanks for any help or pointers... = we've searched=20 Metalink but came up with nothing.
 
 
Jerry
------=_NextPart_000_00A6_01C7FA33.416B5DE0-- -- http://www.freelists.org/webpage/oracle-l