From oracle-l-bounce@freelists.org Wed Apr 20 22:06:20 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j3L36K6d011269 for ; Wed, 20 Apr 2005 22:06:20 -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 j3L36K4Z011265 for ; Wed, 20 Apr 2005 22:06:20 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id CB5AF185CFA; Wed, 20 Apr 2005 21:04:00 -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 15439-07; Wed, 20 Apr 2005 21:04:00 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 483F5185D4F; Wed, 20 Apr 2005 21:04:00 -0500 (EST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B2Cz9rZESFdUjlSdzKbm1nRSy+aTThMGJUWPqmYFYEKIjG/54QybHZJxN72nCWmGdfY+m+3kmsVvkP56GBxa3kfSehLW+tlC3kDD3z0xvj8aCqyD+Lfp1ZD4/a+2k/W2mVcLvy+XIJJno0l0h5gOXQJOtsm8XKfr3Z3JYcxypgM= Message-ID: <264ff93405042019025c3c20ac@mail.gmail.com> Date: Thu, 21 Apr 2005 10:02:10 +0800 From: jame tong To: Yongping Yao , ORACLE-L Subject: Re: tempspace usage In-Reply-To: <70646899050420083194dffec@mail.gmail.com> Mime-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: inline References: <264ff934050419203720fa854d@mail.gmail.com> <7064689905042005007f4f6e4d@mail.gmail.com> <264ff934050420064613434fdb@mail.gmail.com> <70646899050420070736c66029@mail.gmail.com> <264ff9340504200807129d864@mail.gmail.com> <70646899050420083194dffec@mail.gmail.com> X-archive-position: 18713 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: jametong@gmail.com Precedence: normal Reply-To: jametong@gmail.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=ham version=2.63 comment in line. On 4/20/05, Yongping Yao wrote: > I've used partition though every partition occupies about 12GB. And I > subpartitioned :( > Online switch the undo tablespace is a good idea. i agree with you > that SMON cleans UNDO until some other transactions request undo > space. But I still got "cannot extend" error once. It cleaned too > slow? > BTW, I know that when the transaction is running I can link the undo > objects to its SQL using V$ views. But during the transaction > committed and the UNDO space cleaned, how can I get the SQL? I mean > how can I name which transaction or session used up the UNDO and > thougth it has been committed SMON hasn't clean it out. >=20 you can query from the v$sql dynamic perf view. to get it a little . not very acurate. the next query may give you some hint about it. select disk_reads,rows_processed/executions rows_processed_per_execute,sql_= text from v$sql where command_type in (2 /*insert*/,6 /*update*/,7 /*+delete*/) and executions > 0 order by rows_processed desc,command_type desc, > On 4/20/05, jame tong wrote: > > comment in line. > > > > On 4/20/05, Yongping Yao wrote: > > > Well, some statements cannot be tuned more. In our design, these kind > > > of operations are rare (delete the duplicate rows and due to the load > > > speed we do not use unique index). But I did use them these days sinc= e > > > the application did something wrong :( > > if your table is very big , then use partition table will be a must. > > then you can use exchange partition to minimize the undo with it. > > delete from a big table is a bad idea. > > > > > And by the way, SMON clean the undo tablespace? It also has some > > > delay. Some transanctions are commited and they still occupy the undo > > > space. Can it be solved? Or just add more space to the undo > > > tablespace? > > > > if you have a undo tablespace that extended beyond your control. then > > create a new undo tablespace . and change the undo tablespace online > > may be a better solution than to wait the SMON to clean then undo > > tablespace. > > > > within my technical scope. if there were no other transaction request > > the undo from the undo tablespace , oracle will not release this undo > > segment. > > > > > On 4/20/05, jame tong wrote: > > > > I think you tune the sql statement to minimize the temp space usage= . > > > > > > > > > > > > On 4/20/05, Yongping Yao wrote: > > > > > I have a related question. After I run a statement consuming the > > > > > temporary tablespace a lot and commit the transaction, the tables= pace > > > > > is not cleaned soon. Then other sessions got an error something l= ike > > > > > "can't extend ...in ..." which means the temporary tablespace is = not > > > > > enough. Is there something wrong with the background process? > > > > > Do I have to use a separate temporary tablespace or set the tempo= rary > > > > > tablespace autoextend (which I think is not safe and hard to cont= rol > > > > > the datafile size)? > > > > > > > > > > -- > > > > > Yao Yongping > > > > > Learning Oracle, UNIX/Linux... > > > > > Love Reading, Classical Music, Philosophy, Economics etc. > > > > > Blog: http://blog.csdn.net/ > > > > > > > > > > > > > > > -- > > > Yao Yongping > > > Learning Oracle, UNIX/Linux... > > > Love Reading, Classical Music, Philosophy, Economics etc. > > > Blog: http://blog.csdn.net/ > > > > > >=20 > -- > Yao Yongping > Learning Oracle, UNIX/Linux... > Love Reading, Classical Music, Philosophy, Economics etc. > Blog: http://blog.csdn.net/ > -- http://www.freelists.org/webpage/oracle-l