From oracle-l-bounce@freelists.org Thu Sep 23 11:33:55 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i8NGXt925646 for ; Thu, 23 Sep 2004 11:33:55 -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 i8NGXsI25635 for ; Thu, 23 Sep 2004 11:33:54 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 82E2772E66E; Thu, 23 Sep 2004 11:38:11 -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 14862-62; Thu, 23 Sep 2004 11:38:11 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 0555F72E78B; Thu, 23 Sep 2004 11:36:08 -0500 (EST) Message-ID: Date: Thu, 23 Sep 2004 09:28:04 -0700 From: Jared Still To: mwf@rsiz.com Subject: Re: DB Links (VLDB) Cc: "Oracle-L (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit References: <30462D80AA52E74698512ADCC4F7EAA314E271B6@EXCHANGE> X-archive-position: 9988 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: jkstill@gmail.com Precedence: normal Reply-To: jkstill@gmail.com X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org Interesting thoughts Mark. It brings to mind the idea of a global statistics server. No doubt a future part of grid computing. Jared -- Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist On Thu, 23 Sep 2004 11:16:33 -0400, Mark W. Farnham wrote: > Only a historical note, but this is one of a very few outstanding items from > the Oracle VLDB group of the early 1990's that has not been definitively > addressed. The hint was the interim solution and I don't think establishing > a statistical metric framework for inter-database access ever has reached > the action item level on anyone's priority list. I'm not sure it is even > reasonably do-able short of a fully deployed grid with knowledge of the > stats on all the databases involved in the query as well as the latency and > available capacity of the network paths required. Even then the best > statistical plan would be subject to actions external to the database engine > that sucked up (or stopped using) network capacity. And what abstract > costing should be put on network load? Should the cost be to minimize > response time or network load, or something else? > > (I'll gratefully be educated on this point if there is a statistic the > optimizer could look at to sort out such plans.) > -- http://www.freelists.org/webpage/oracle-l