From oracle-l-bounce@freelists.org Thu Sep 8 15:50:09 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j88Ko9Mf021771 for ; Thu, 8 Sep 2005 15:50:09 -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 j88Ko5IP021758 for ; Thu, 8 Sep 2005 15:50:05 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 30AA71E95E9; Thu, 8 Sep 2005 15:49:59 -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 02410-10; Thu, 8 Sep 2005 15:49:59 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 974A41E8F90; Thu, 8 Sep 2005 15:49:58 -0500 (EST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=IU0XTbf9T3pXmyh1pjVLKkBGdD9TBp26NrHkODfWU1Efd25jYRtWQwWcWPQ3iqdz/3c2uJHItB5dKHkZEKde2JHOO0P033zZbdN2P4LLFwwmfugkP4Nrq0AAx+PvxnFJ3jXTUXGeI/6/vjKLomRuHEoM68ISS2zUAqnAtUNu4rs= Message-ID: <47a6f72b0509081348112dff40@mail.gmail.com> Date: Thu, 8 Sep 2005 14:48:07 -0600 From: Barbara Baker To: oracle-l@freelists.org Subject: MGMT_DB_SIZE_GTT trunc 10g Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9841_27831930.1126212487429" X-archive-position: 25181 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: barb.baker@gmail.com Precedence: normal Reply-To: barb.baker@gmail.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-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, NORMAL_HTTP_TO_IP,UPPERCASE_25_50 autolearn=no version=2.63 ------=_Part_9841_27831930.1126212487429 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Solaris 9; Oracle 10.1.0.3 Now I remember some of the reasons why I detest OEM so very much. User DBSNMP is truncating table MGMT_DB_SIZE_GTT twice every 30 minutes.=20 The only reference I can find to this is metalink note 292280.1, which seem= s=20 to indicate that this is expected behavior. (Gee, I didn't expect it!) I=20 wouldn't think that truncating a global temp table every 30 minutes would b= e=20 so very good for performance. Anyone else seen this? Is it causing production problems for you? (We're no= t=20 yet live with this system) Thanks! Barb (Here's a snipet from my audit log:) USERID TIMEST Action name Obj Name SES_ACTIONS ------------ ------------------ -------------- --------------------=20 ----------- DBSNMP 08-Sep-2005 10:54 TRUNCATE TABLE MGMT_DB_FILE_GTT DBSNMP 08-Sep-2005 10:54 TRUNCATE TABLE MGMT_DB_SIZE_GTT DBSNMP 08-Sep-2005 11:24 TRUNCATE TABLE MGMT_DB_FILE_GTT DBSNMP 08-Sep-2005 11:24 TRUNCATE TABLE MGMT_DB_SIZE_GTT DBSNMP 08-Sep-2005 11:54 TRUNCATE TABLE MGMT_DB_FILE_GTT DBSNMP 08-Sep-2005 11:54 TRUNCATE TABLE MGMT_DB_SIZE_GTT DBSNMP 08-Sep-2005 12:24 TRUNCATE TABLE MGMT_DB_FILE_GTT DBSNMP 08-Sep-2005 12:24 TRUNCATE TABLE MGMT_DB_SIZE_GTT DBSNMP 08-Sep-2005 12:54 TRUNCATE TABLE MGMT_DB_FILE_GTT DBSNMP 08-Sep-2005 12:54 TRUNCATE TABLE MGMT_DB_SIZE_GTT ------=_Part_9841_27831930.1126212487429 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Solaris 9; Oracle 10.1.0.3

Now I remember some of the reasons why I detest OEM so very much.
User DBSNMP is truncating table MGMT_DB_SIZE_GTT twice every 30 minutes.&nb= sp;
The only reference I can find to this is metalink note 292280.1, which seems to indicate that this is expected behavior.  (Gee, I didn't expect it!)  I wouldn't think that truncating a global temp table every 30 minutes would be so very good for performance.

Anyone else seen this?  Is it causing production problems for you?&nbs= p; (We're not yet live with this system)
Thanks!
Barb

(Here's a snipet from my audit log:)

USERID       TIMEST           &nb= sp; Action name    Obj Name            = ; SES_ACTIONS
------------ ------------------ -------------- -------------------- -------= ----
DBSNMP       08-Sep-2005 10:54  TRUNCATE= TABLE MGMT_DB_FILE_GTT
DBSNMP       08-Sep-2005 10:54  TRUNCATE= TABLE MGMT_DB_SIZE_GTT
DBSNMP       08-Sep-2005 11:24  TRUNCATE= TABLE MGMT_DB_FILE_GTT
DBSNMP       08-Sep-2005 11:24  TRUNCATE= TABLE MGMT_DB_SIZE_GTT
DBSNMP       08-Sep-2005 11:54  TRUNCATE= TABLE MGMT_DB_FILE_GTT
DBSNMP       08-Sep-2005 11:54  TRUNCATE= TABLE MGMT_DB_SIZE_GTT
DBSNMP       08-Sep-2005 12:24  TRUNCATE= TABLE MGMT_DB_FILE_GTT
DBSNMP       08-Sep-2005 12:24  TRUNCATE= TABLE MGMT_DB_SIZE_GTT
DBSNMP       08-Sep-2005 12:54  TRUNCATE= TABLE MGMT_DB_FILE_GTT
DBSNMP       08-Sep-2005 12:54  TRUNCATE= TABLE MGMT_DB_SIZE_GTT

------=_Part_9841_27831930.1126212487429-- -- http://www.freelists.org/webpage/oracle-l