I have an Oracle table in a live production environment and the table is over half a gig in size. Is it possible to change this normal Oracle table from being heap organised to index organised or is this only achievable by moving the data from this table to another new table which is index organised? Either way, I would be grateful if you could you please list the steps involved in this procedure.
There is no way to alter a table to make it index-organized table. Instead you can redefine the table(using DBMS_REDEFINITION)or can create new table using CTAS.
Example:
create table t2 (
id number, first_name varchar2(20),
constraint pk_id primary key (id)
)
organization index
as select * from t1;
I never used DBMS_REDEFINITION but with CTAS it is not only step to create table if it is production.
List all indexes, constraints, foreign keys and so on based on system views
Prepare create index, constraints and alter foreign keys statements. prepare list of triggers, procedures that depend on table.
Create table as select (consider lock before that step if you can)
Create all indexes, constraints with prepared statements from step 2
Swap table names and swap foreign keys (this step may cause some errors if you hit insert on foreign keys (if you expect it on that time you should lock the table and tables referencing by foreign key).
Compile dependent objects from 2 (if you locked tables unlock here)
(if you haven't locked on step 3) Insert into table select * from new minus select * from old; or if you have timstamp of inserting row just insert new rows.
I hope the list is complete.
Related
I want to generate dynamically the below alter code(the below one is an eg, it will differ table to table) for all the partitioned tables in 12c DB.
Some tables may be partitioned on RANGE, LIST etc.
The column name, partition type will also change as per the table.
ALTER TABLE EMP
MODIFY PARTITION BY RANGE (START_DATE)
( PARTITION P1 VALUES LESS THAN (date'2021-1-1') ) ONLINE;
I have already created tables without partition in another db and now want to partition those tables which were partitioned in the source db. So want a simple script which can create code to partition the tables in the target db. Note - all tables have different partition and my goal is to make them sync with source. Only data differs in both the DBs.
I’ve made an attempt to create partition on test table using virtual column. This approach is working good for PARENT or standalone tables. However, I cannot create REFERENCE partition on CHILD table if the PARENT table is PARTITIONED using virtual column. I get the following error on create table of CHILD table
ORA-14659: Partitioning method of the parent table is not supported
Oracle Version details:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
PL/SQL Release 12.2.0.1.0 - Production
Please find the script below.
--######################PARENT TABLE###########################################
DROP TABLE BILL_HEADER_TST;
CREATE TABLE BILL_HEADER_TST
(
BILL_HDR_SID NUMBER (30) NOT NULL,
TCN VARCHAR2 (21 BYTE) NOT NULL,
TCN_DATE DATE,
PROGRAM_CID NUMBER,
CONSTRAINT XPKBILL_HEADER_TST PRIMARY KEY (BILL_HDR_SID),
PARTN_KEY NUMBER
AS ( PROGRAM_CID
|| TO_NUMBER (TO_CHAR (TCN_DATE, 'YYYYMM')))
VIRTUAL
)
PARTITION BY LIST (PARTN_KEY) AUTOMATIC (PARTITION PDEFAULT VALUES (1201401));
------------------LOCAL INDEXES------------------------------------------------
CREATE INDEX XIE33BILL_HEADER_TST
ON BILL_HEADER_TST (TCN_DATE)
LOCAL;
CREATE INDEX XIE38BILL_HEADER_TST
ON BILL_HEADER_TST (PROGRAM_CID)
LOCAL;
---------------------INDEXES---------------------------------------------------
CREATE UNIQUE INDEX XAK1BILL_HEADER_TST
ON BILL_HEADER_TST (TCN)
LOGGING
NOPARALLEL;
--#############CHILD TABLE#####################################################
DROP TABLE BILL_LINE_TST;
CREATE TABLE BILL_LINE_TST
(
BILL_LINE_SID NUMBER (30) NOT NULL,
BILL_HDR_SID NUMBER (30) NOT NULL,
CLM_TYPE_CID NUMBER (3),
PROGRAM_CID NUMBER,
CONSTRAINT XPKBILL_LINE_TST PRIMARY KEY (BILL_LINE_SID),
CONSTRAINT XFK17_BILL_LINE_TST FOREIGN KEY
(BILL_HDR_SID)
REFERENCES BILL_HEADER_TST (BILL_HDR_SID) ON DELETE CASCADE
)
PARTITION BY REFERENCE (XFK17_BILL_LINE_TST)
ENABLE ROW MOVEMENT;
From the SQL Language manual
Automatic list partitioning is subject to the restrictions listed in "Restrictions on List Partitioning". The following additional restrictions apply:
An automatic list-partitioned table must have at least one partition
when created. Because new partitions are automatically created for
new, and unknown, partitioning key values, an automatic
list-partitioned table cannot have a DEFAULT partition.
Automatic list partitioning is not supported for index-organized
tables or external tables.
Automatic list partitioning is not supported for tables containing
varray columns.
You cannot create a local domain index on an automatic
list-partitioned table. You can create a global domain index on an
automatic list-partitioned table.
An automatic list-partitioned table cannot be a child table or a
parent table for reference partitioning.
Automatic list partitioning is not supported at the subpartition
level.
Is it possible to add ON DELETE CASCADE to a foreign key that is used as a partitioning key when used with PARTITION BY REFERENCE? I'm talking about an already exiting table.
My solution would be to drop the constraint and recreate it, but it doesn't work, as I cannot drop a constraint that is used by PARTITION BY REFERENCE.
I get
SQL Error: ORA-14650: operation not supported for reference-partitioned tables
Oracle 11g.
drop table y;
drop table x;
create table x (a number primary key) partition by hash (a);
create table y (a number not null,
constraint y_x_fk foreign key(a) references x(a))
partition by reference(y_x_fk);
alter table y drop constraint y_x_fk;
I believe there is no option in ALTER...MODIFY to an inline option to make the extant constraint cascade; I think you will indeed need to drop and recreate, or equivalent.
I also agree, it looks like there is no clean way to drop and recreate a partition-reference constraint either; I believe you'll be facing a redefiniton to get there.
To make matters worse, it looks like the DBMS_REFEFINITION enhancements available in 12c won't get you there in a nice one-step redef, as DBMS_REDEFINITION doesn't support reference partitioning.
I think you'll need to do an old-school redef. (It could still be worth trying some DBMS_REDEFINITION with a hand-crafted replacement, but I would be prepared for at least a bit of downtime).
An approach like the below example could get you there (with downtime). Depending on your availability needs, other approaches could minimize the downtime in this example.
Make a replacement table with the desired CASCADING FK:
create table y_temp (a number not null,
constraint y_temp_x_fk foreign key(a) references x(a) ON DELETE CASCADE)
partition by reference(y_temp_x_fk);
Then go read-only:
ALTER TABLE X READ ONLY;
ALTER TABLE Y READ ONLY;
Then sync Y and Y_TEMP:
INSERT INTO Y_TEMP SELECT Y.A FROM Y;
COMMIT;
Then make the swap:
ALTER TABLE Y RENAME TO Y_OLD;
ALTER TABLE Y_TEMP RENAME TO Y;
DROP TABLE Y_OLD;
ALTER TABLE Y RENAME CONSTRAINT y_temp_x_fk TO y_x_fk;
And bring things back up for WRITE
ALTER TABLE X READ WRITE;
Then test it:
INSERT INTO X VALUES (1);
INSERT INTO Y VALUES (1);
SELECT * FROM Y;
A
1
DELETE FROM X;
1 row deleted.
And the cascade:
SELECT * FROM Y;
no rows selected
I have a datamart with 5 dimension table and a fact table.
I'm trying to clean a dimension table that has few rows (4000 rows). But, the fact table have millions rows (25GB)(Indexes and partitions).
When I try to delete a row in the table dimension, the process becomes very slow. It's just as slow despite the absence of relationship with a row in the fact table (cascade delete).
Is there any way to optimize this?. Thanks in advance.
Presumably, there is a cascading delete of some sort between the dimension table and the fact table.
Adding an index on the key column in the fact table may be sufficient. Then Oracle can immediately tell if/where any given value is.
If that doesn't work, drop the foreign key constraint altogether. Delete the unused values and add the constraint back in.
You could try these strategies as well :
create another copy of the fact table but, without the dim foreign key column of the table to be cleaned.
create fact_table_new as
select dim1_k, dim2_k, dim3_k, dim4_k, dim5_k (not this column), fact_1, fact_2, ...
from fact_table ;
or
update fact_table
set dim5_fk_col = null
where dim5_fk_col in (select k_col from dim5_table) ;
I need to update the primary key of a large Index Organized Table (20 million rows) on Oracle 11g.
Is it possible to do this using multiple UPDATE queries? i.e. Many smaller UPDATEs of say 100,000 rows at a time. The problem is that one of these UPDATE batches could temporarily produce a duplicate primary key value (there would be no duplicates after all the UPDATEs have completed.)
So, I guess I'm asking is it somehow possible to temporarily disable the primary key constraint (but which is required for an IOT!) or alter the table temporarily some other way. I can have exclusive and offline access to this table.
The only solution I can see is to create a new table and when complete, drop the original table and rename the new table to the original table name.
Am I missing another possibility?
You can't disable / drop the primary key constraint from an IOT, since it is a unique index by definition.
When I need to change an IOT like this, I either do a CTAS (create table as) for a new plain heap table, do my maintenance, and then CTAS a new IOT.
Something like:
create table t_temp as select * from t_iot;
-- do maintenance
create table t_new_iot as select * from t_temp;
If, however, you need to simply add or join a new field to the existing key, you can do this in one step by creating the new IOT structure, then populating directly from the old IOT with a query.
Unfortunately, this is one of the downsides to IOTs.
I would recommend following method:
Create new IOT table partitioned by system with single partition
with exactly same structure as current one.
Lock current IOT table to prevent any DML.
insert into new table as select from current table changing PK values in select. This step
could be repeated several times if needed. In this case it's better
to do it in another session to keep lock on original table.
Exchange partition of new table with original table.