Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from puck1183.startdedicated.com (localhost [127.0.0.1]) by puck1183.startdedicated.com (Postfix) with ESMTP id D90631960564 for ; Mon, 12 Dec 2016 15:30:39 +0100 (CET) Received: from turing.freelists.org (turing.freelists.org [206.53.239.180]) by puck1183.startdedicated.com (Postfix) with ESMTPS for ; Mon, 12 Dec 2016 15:30:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id DA04E643A4; Mon, 12 Dec 2016 09:30:35 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfue1ZshPSVU; Mon, 12 Dec 2016 09:30:35 -0500 (EST) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 324D764391; Mon, 12 Dec 2016 09:30:23 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Mon, 12 Dec 2016 09:29:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 780F564312 for ; Mon, 12 Dec 2016 09:29:01 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM6WpFrzG6Dq for ; Mon, 12 Dec 2016 09:29:01 -0500 (EST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id E746B642F9 for ; Mon, 12 Dec 2016 09:29:00 -0500 (EST) Received: from [91.102.136.106] by 3capp-gmx-bs07.server.lan (via HTTP); Mon, 12 Dec 2016 15:28:59 +0100 MIME-Version: 1.0 Message-ID: From: "Ingrid Voigt" To: oracle-l@freelists.org Subject: Aw: Re: flashback a standby database Content-Type: text/html; charset=UTF-8 Date: Mon, 12 Dec 2016 15:28:59 +0100 Sensitivity: Normal In-Reply-To: <3ee063ec-f942-06ec-b16b-0ae8ac36fd33@gmail.com> References: , <3ee063ec-f942-06ec-b16b-0ae8ac36fd33@gmail.com> X-UI-Message-Type: mail X-Provags-ID: V03:K0:jEXxwjjWCyWDEjXmTD7IOEgN0c4/XIg0+mNDaAG2jYX UVdzXg04aQJot7BhlKsB/MXDv2Wx9GT4icb3j/2cIpO6r/um2P 9KhGiqMRcNoKKvCBn8q5qvLufcVG5HGXBQTbXJEFyboo3b20Tl zSu2n2AqIJjM1mWJPdB1uLpMk2GCx0hfcKpz0eYy5V9+yYk6je U503eHfNQoO2tB3ikGJNWvFHZR0VOUlN2cW+SUYt4AebWpnHQq T1tzCGVdwGSTzCPiaUh6tS+hXR3FWPgR95fme0Q0/XBMfSHPzW Dd0wPU= X-UI-Out-Filterresults: notjunk:1;V01:K0:LvsGHy5ocXU=:HtGx+McP/QmD1wr+Kc2zTe UTDJRhaRbRAmLstMBLxAQAxytPS6JiihIEgRxFX4tJVkFTD177WUPSwKYCaUlYkEArEe5akfY ni6DPBU8KeEpInENbUXABCxsogfJCbvNtyZYFIZ8scNXjAWxgE05ldSte65RTwbo3ix1xp+aB dF2NLTwCGvnKVHyyE2HlbSH2fErSF5yhzd36OodcVuBtnzn5EWmz/sBb9i7d8NDDiIXJ1ibvI ULcjnBFoz5Rjvnm9Dw8/gGihmg0WKHH3BzhS/6rZvr5Fabvu9Vc1LIQimQsSL/JzkrfPmDM1p 5WVwlBamvCv8ejj9wLLNewspe1e3JltNZ/Qf7rFBJ1GJdxiOP3xae11/0pd9fkSifbo68B9Hn m7Dm7p41d6EPDO9n2yCxlNejxo1Wl7AhS7xJp5xuHsOJv0+NF0+oBKYGlEEdAsSuj9wxx5IK3 mHFRE3Eq6Q== X-archive-position: 67085 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: giantpanda@gmx.net Precedence: normal Reply-To: giantpanda@gmx.net List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l
What can be done on a snapshot standby is moving 500GB data, indexes and lobs from
one tablespace to another. The flashback took a while, but there were no problems.
After a few hours the database had been converted back to physical standby without
further input from me.
 
I believe the limits are the same you would have for a "normal" flashback database, i.e.
try to stay away from datafile operations.
 
Regards
Ingrid
 
 
Gesendet: Montag, 12. Dezember 2016 um 15:01 Uhr
Von: "Mladen Gogala" <gogala.mladen@gmail.com>
An: oracle-l@freelists.org
Betreff: Re: flashback a standby database
On 12/12/2016 05:35 AM, Howard Latham wrote:
RH 4
Oracle 11.2
 
I've searched but haven't found the usual list Oracle provides on limits to this feature. 
Does this mean I can do ANYTHING  to a standby database while it is activated then flash it back to a physical standby later? 

Well, I haven't tried anything drastic, like "DROP TABLESPACE <> INCLUDING CONTENTS AND DATAFILES", but the testing that one of my clients was conducting did include add columns and constraints to the tables and then using regular DML. There were no problems. I think that "anything" means "anything within reasonable limits".
Regards
 

 

-- 
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217
-- http://www.freelists.org/webpage/oracle-l