I would guess we will be running into that same issue, won't we?
Regards
Lothar
Am 24.02.2021 um 15:02 schrieb Shane Borden (Redacted sender sborden76
for DMARC):
Sounds like DBMS_REDEFINITION with partitioning, securefile and perhaps bigfile tablespace is in order. Everything can be pre-done before the cutover.
---
Thanks,
Shane Borden
sborden76@xxxxxxxxx <mailto:sborden76@xxxxxxxxx>
On Feb 24, 2021, at 9:00 AM, Tim Gorman <tim.evdbt@xxxxxxxxx <mailto:tim.evdbt@xxxxxxxxx>> wrote:
At a billion rows and growing, please convince the customer to partition the table, especially if a move/rebuild is already planned? Such a table should have data lifecycle requirements (i.e purge, etc) upcoming, if not already known, so it makes sense to build these into the structure of the table, rather than relying on massive DML operations. Range partitioning on a DATE column is appropriate as a starting consideration.
On 2/24/2021 4:59 AM, l.flatz@xxxxxxxxxx wrote:
Hi,
we have to move a completely fragmented table in an other Tablespace.
The table contains About a billion rows (not partitioned ). It contains a BLOB column (securefile) storing a PDF.
The big issue is the reconstruction of a text Index.
Alter table move does fail in the sense that after a while it stucks with "write complete" waits.
My collegue wants alter table move because she does not want to rebuild the text index. That is a Nightmare because of parsing .
Questions:
1. I believe even alter table move will rebuild the index behind
the Scenes anyway. True?
2. Will the LOB Locator Change if the LOb is relocted? (So that
means does the lob locator have a physical charateristics as a
rowid)
3. Is there a way to rebuild the text index but avoid reparsing?
4. what is the best practise to move such a table to a new
tablespace? ( I have a Code solution that pulls a CLOB over a db
link using a pipelined table function. I could Combine that with
this idea : http://mareklall.blogspot.com/2015_06_01_archive.html)
Reagards
Lothar
