Alternatively, if you want a short-term method to "undoing" a partition
drop, you could consider first exchanging the partition in question with an
empty table. Then you can wait a day or two to see whether the sky falls
due to the absent data before you actually drop it.
I get a sense, here that the OP (Mostafa) may not be completely comfortable
with the concepts around partitioning and partition management. If that is
the case, I would invite him to review the reference manuals, especially
any "concepts" material, on the subject of partitioning before he proceeds
with work that may permanently alter his data.
On Mon, Jun 15, 2015 at 8:23 AM, John Thomas <jt2354@xxxxxxxxx> wrote:
Mostafa,
Should be nothing to stop you dropping these partitions, and if all your
indexes are local, nothing for you to do with indexes either.
However, if this is data you might want back, you might consider putting
them in separate tablespaces and using transportable tablespace export
before you offline then and back the tablespace and export metadata up.
That way if the data is needed again it can be onlined in seconds with no
need for a database restore.
Just depends what your requirements are.
Regards
J
On Mon, 15 Jun 2015 12:55 Mostafa Eletriby <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
Hello folks,
I have some questions regarding my case.
I have database 11g R1 Prod at Unix HP - UX , database is in archive
mode. there exist some tables partitioned with huge data and there are
local indexes.
My question is that I need to drop these partitions , Is it better to
make them offline then drop them smoothly after checking the effect at data
and data consistency or go ahead to drop after taking backup & check
required steps for restoration.
Also ,I need to know the steps to be performed after dropping those
partitions regarding the local indexes & how to check them and to know all
the effect in details.
Thanks
