From oracle-l-bounce@freelists.org Mon Apr 12 21:47:24 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i3D2lJa32665 for ; Mon, 12 Apr 2004 21:47:24 -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 i3D2lJ632660 for ; Mon, 12 Apr 2004 21:47:19 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A8FAF6346BD; Mon, 12 Apr 2004 21:41:53 -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 31193-99; Mon, 12 Apr 2004 21:41:53 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C8780634588; Mon, 12 Apr 2004 21:41:52 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Mon, 12 Apr 2004 21:40:39 -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 1896F634485 for ; Mon, 12 Apr 2004 21:40:39 -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 00590-02 for ; Mon, 12 Apr 2004 21:40:38 -0500 (EST) Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 9C731634470 for ; Mon, 12 Apr 2004 21:40:38 -0500 (EST) Received: from medo.adelphia.net ([68.68.128.39]) by mta13.adelphia.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP id <20040413025053.USQE13425.mta13.adelphia.net@medo.adelphia.net> for ; Mon, 12 Apr 2004 22:50:53 -0400 Date: Mon, 12 Apr 2004 22:50:52 -0400 From: Mladen Gogala To: oracle-l@freelists.org Subject: Re: Database Archive Message-ID: <20040413025052.GA1958@medo.adelphia.net> References: Mime-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: (from tim@sagelogix.com on Mon, Apr 12, 2004 at 22:18:39 -0400) X-Mailer: Balsa 2.0.17 Lines: 30 X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 2910 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: mgogala@adelphia.net Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org Tim, besides not forgetting to set the new boundaries for partition key when data is moved to the online storage, there is another thing to be careful. Namely, DDL changes to the original table, like adding columns and/or changing data types (extending column size is a classical example) can render partition impossible to bring back online. As the original article from CW would have it, these things have to be carefully planned, documented and treated as projects. My suggestion is to first exchange partition with an empty table, then export that table, so that the result is an entity which doesn't depend on the structure of the original table for being restored. With tables having 100+ GB in size, archiving is a very serious project which shouldn't be taken lightly. Also, a mandatory part of a successful archiving project is bragging about it on this list. On 04/12/2004 10:18:39 PM, Tim Gorman wrote: > Zhu, > > If its OK to actually remove data from a table to an offline archive store, > then why isn't it OK to restrict on the partitioning key column in order to > restrict the volume of data being queried? > > True enough that people will forget to restrict on the partition key; human > nature and all that. But if they think it through, then what they are > really complaining about is having access to all the data that otherwise > would have been offlined. If they do not want to query that data, then they > should't query that data. If they really want to query the data that would > otherwise have been archived and removed, then they should appreciate it. > -- Mladen Gogala Oracle DBA ---------------------------------------------------------------- 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 -----------------------------------------------------------------