From oracle-l-bounce@freelists.org Tue Jun 8 13:39:02 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i58IclF11024 for ; Tue, 8 Jun 2004 13:38:57 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i58Icb610999 for ; Tue, 8 Jun 2004 13:38:47 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 9770672C53F; Tue, 8 Jun 2004 13:24:22 -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 21142-72; Tue, 8 Jun 2004 13:24:22 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id CB50E72C393; Tue, 8 Jun 2004 13:24:21 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 08 Jun 2004 13:22:47 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id DC3A172C532 for ; Tue, 8 Jun 2004 13:22:46 -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 20526-53 for ; Tue, 8 Jun 2004 13:22:46 -0500 (EST) Received: from hrdcgate.nhq.hrdc-drhc.gc.ca (hrdcgate.nhq.hrdc-drhc.gc.ca [198.103.152.3]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with SMTP id 5CCBE72C393 for ; Tue, 8 Jun 2004 13:22:46 -0500 (EST) Received: from svmailsw2.hq-ac.prv by hrdcgate.nhq.hrdc-drhc.gc.ca via smtpd (for freelists-180.iquest.net [206.53.239.180]) with SMTP; Tue, 8 Jun 2004 18:41:59 +0000 Received: from svsmtpvs1.hq-ac.prv (10.54.254.9) by svsmtpsw2.hq-ac.prv (7.0.020) id 40C541B8000117B7 for oracle-l@freelists.org; Tue, 8 Jun 2004 14:41:59 -0400 Received: from nccs01.hrdc-drhc.net ([10.54.254.201]) by svsmtpvs1.hq-ac.prv with InterScan Messaging Security Suite; Tue, 08 Jun 2004 14:41:58 -0400 Received: from NCEV02.hrdc-drhc.net ([10.54.249.14]) by nccs01.hrdc-drhc.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Jun 2004 14:41:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44D88.4734C24A" Subject: can table locking improve performance ?? Date: Tue, 8 Jun 2004 14:41:57 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: can table locking improve performance ?? Thread-Index: AcRNiEcmAxYONd70SSK13tjmpg8CHw== From: To: X-OriginalArrivalTime: 08 Jun 2004 18:41:57.0954 (UTC) FILETIME=[4740DA20:01C44D88] X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 2271 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: babette.turnerunderwood@sdc-dsc.gc.ca Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org ------_=_NextPart_001_01C44D88.4734C24A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have an initial load process that is very long running. The update of 38M rows takes hours and hours. There are two users on the entire system, us doing the load and another user to look at some of the v$ views during the load process. Updates need to put exclusive row-level locks before being able to update rows. If we do a table level lock PRIOR to the update statement, what effect will it have on performance. Intuitively, we think it should be more efficient, but I don't know if Oracle will be more efficient in checking locks when updating rows or does the exact same source code apply, regardless if there is a table level lock. In other words, in this case, can a table level lock improve performance ? - thanks Babette ------_=_NextPart_001_01C44D88.4734C24A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable can table locking improve performance ??

We have an initial load process that is = very long running.
The update of 38M rows takes hours and = hours.
There are two users on the entire = system, us doing the
load and another user to look at some = of the v$ views
during the load process.

Updates need to put exclusive row-level = locks before
being able to update rows. If we do a = table level lock
PRIOR to the update statement, what = effect will it
have on performance. Intuitively, we = think it should be
more efficient, but I don't know if = Oracle will be more
efficient in checking locks when = updating rows
or does the exact same source code = apply, regardless
if there is a table level lock.

In other words, in this case, can a = table level lock
improve performance ?

- thanks
Babette

------_=_NextPart_001_01C44D88.4734C24A-- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------