Re: oracle 9 export all without 1 table
From: Maxim <mdemenko_at_gmail.com>
Date: Sun, 1 Mar 2009 06:34:31 -0800 (PST)
Message-ID: <9a35f24e-bc06-4ae4-bf0e-b9d9836598de_at_r27g2000vbp.googlegroups.com>
You are correct on it, but my intention wasn't to make this suggestion to be considered seriously anyway.
The post i answered to was about idea to make the table which should be exported invisible to exp. But, instead, it would make this table unavailable to all, not only to exp.
Afaik, there is no *documented* method to exclude a table from export, except already suggested method with rls policy and trigger which fires *only* for exp.
There are some undocumented methods to do that,but generate parfile with list of desired tables is very good and straightforward way , copy tables via dblink is equally acceptable alternative, precreate table in target schema and raise an error by import - i don't see any drawbacks as well, in contrast, move table in another schema - *is not acceptable* in most environments.
Equally, drop and flashback is not an acceptable solution - besides unavailability of that table for some time, there is a risk to not get the table back...
Date: Sun, 1 Mar 2009 06:34:31 -0800 (PST)
Message-ID: <9a35f24e-bc06-4ae4-bf0e-b9d9836598de_at_r27g2000vbp.googlegroups.com>
You are correct on it, but my intention wasn't to make this suggestion to be considered seriously anyway.
The post i answered to was about idea to make the table which should be exported invisible to exp. But, instead, it would make this table unavailable to all, not only to exp.
Afaik, there is no *documented* method to exclude a table from export, except already suggested method with rls policy and trigger which fires *only* for exp.
There are some undocumented methods to do that,but generate parfile with list of desired tables is very good and straightforward way , copy tables via dblink is equally acceptable alternative, precreate table in target schema and raise an error by import - i don't see any drawbacks as well, in contrast, move table in another schema - *is not acceptable* in most environments.
Equally, drop and flashback is not an acceptable solution - besides unavailability of that table for some time, there is a risk to not get the table back...
Best regards
Maxim
On 1 Mrz., 14:39, "bob123" <bob..._at_gmail.com> wrote:
> > Isn't it much simplier then - drop table, export the rest,flashback to
> > before drop?
> > ;-)
>
> flashback table isn't available in 9i
Received on Sun Mar 01 2009 - 08:34:31 CST