I use Oracle 10g. Since months I have the following error regarding a table:
ORA-12986: columns in partially dropped state. Submit ALTER TABLE DROP COLUMNS CONTINUE
The statement ALTER TABLE DROP COLUMNS CONTINUE fails for overtime.
I have no DBA privileges on this database.
What could I do? Drop & recreate the table?
It's a massive table with million of records.
What I tried:
Once upon a time, I made the following command to set some columns
in unused state:
ALTER TABLE hr.admin_emp SET UNUSED (hiredate, mgr);
Then, I gave the following command:
ALTER TABLE hr.admin DROP UNUSED columns;
The system hangs up, the operation is too long, so it faults.
Now the table hr.admin has two columns in partially dropped state,
and I can't go neither forward, nor backward.
I don't understand why this happened.
I made the following steps, the system hangs up at STAGE TWO:
STAGE ONE
============
SQL> select * from user_unused_col_tabs;
TABLE_NAME COUNT
----------- ----------
TEMP 1
STAGE TWO
============
SQL> alter table temp drop unused columns;
Table altered.
STAGE THREE
=============
SQL> select * from user_unused_col_tabs;
no rows selected
Checkpoint 500 option
I am trying again with the following statement:
ALTER TABLE MYUSER.MYTABLE DROP COLUMNS CONTINUE CHECKPOINT 500;
Could the CHECKPOINT 500 option help me?
We have given for about twelve consecutive times the command:
ALTER TABLE MYUSER.MYTABLE DROP COLUMNS CONTINUE CHECKPOINT 250;
The statement was automatically killed every 48 hours, this is the reason because we had to launch it several times.
About 500 hours of elaboration to definitely drop the columns in partially dropped state...!!
It is confirmed that CHECKPOINT 250 makes a "commit", so at the next launch of the same command, you start from the point of stop.
Related
I have one table backup on which I had applied one trigger upd_trig. Now, I dropped my table and then I checked, whether all the associated trigger/index will also been dropped or will remain there.
As I found some discussion here,and they said Trigger/Index all will be dropped,once we drop our table. But, it seems, trigger still exist. Can anyone explain, what exactly happens, when we drop the table
SQL> drop table backup;
Table dropped.
SQL> select text from user_source;
TEXT
----------------------------------------------------------------------------------------------------
TRIGGER
"BIN$Dg5j/bf6Rq6ugyN5ELwQkw==$0" BEFORE UPDATE ON backup FOR EACH ROW
BEGIN
INSERT INTO BACKUP VALUES(USER,:OLD.ENAME,SYSDATE);
END;
9 rows selected.
SQL> select count(*) from user_triggers;
COUNT(*)
----------
1
SQL> select trigger_name from user_triggers;
TRIGGER_NAME
------------------------------
BIN$Dg5j/bf6Rq6ugyN5ELwQkw==$0
The table has been dropped, but it is in the recycle bin, from which it can be recovered using the flashback commands (flashback ... before drop]. The name showing as BIN$... is a bit of a giveaway. The trigger is also showing with a BIN$... name, indicating that it is in the recycle bin too, and any indexes will be too.
You can empty the recycle bin to permenantly remove the objects in it. To drop a table immediately, without it going to the recycle bin, you can add the keyword purge to the drop command, as explained in the documentation. That will also drop any indexes and triggers immediately.
If it wasn't dropped automatically, then the trigger would be irrelevent anyway, since you couldn't perform any DML on the dropped table, so it could never fire. That's if the table the trigger is against is dropped. Your trigger is weird, it's inserting into the same table. Normally you'd have a trigger on one table insert into your backup table (well, for one use of triggers). In that case, dropping the backup table would invalidate the trigger on the live table, but would not drop it. Only dropping the live table would drop the trigger on the live table.
i want to update a partition key. the partition is as below
PARTITION_NAME LAST_ANALYZED NUM_ROWS BLOCKS SAMPLE_SIZE HIGH_VALUE
PORTAL_SERVICE_1 12/8/2016 4133 174 4133 1
PORTAL_SERVICE_2 6/8/2016 4474 174 4474 2
PORTAL_SERVICE_3 10/8/2016 29602 2014 29602 3
PORTAL_SERVICE_OTHERS 24/5/2016 0 110 DEFAULT
this partition is applied on column Portal_Service_id. i want to update the value of portal service id from 2 to 1.
when i try
update trans set PORTAL_SERVICE_ID = 1 where ID = 2054;
i get error:
Error report -
SQL Error: ORA-14402: updating partition key column would cause a partition change
14402. 00000 - "updating partition key column would cause a partition change"
i am not allowed to use Enable Row Movement.
Can anybody please suggest any alternative to update the row.
can anybody shed some light if this can be used in the scenario:
UPDATE <table_name> PARTITION (<partition_name>)
SET <column_name> = <value>
WHERE <column_name> <condition> <value>;
to work around the error "ORA-14402: updating partition key column would cause a partition change" you can follow these steps
1) Check if for your table is enabled the row_movement
SELECT owner,
table_name,
row_movement
FROM dba_tables
WHERE table_name in ('YOUR_TABLE');
2) If is disabled you can enable movement with this script
alter table YOUR_TABLE enable row movement;
After that you can update the partition key column
Most of the other answers have pointed out one part of the solution, which is:
alter table <table_name> enable row movement
However, there's more to it than this. Enabling row movement has some tradeoffs, which are pointed out here: http://www.dba-oracle.com/t_enable_row_movement.htm
In my case, this led me to double check why we were using a partition in the first place. Ideally, a partition is for data that won't move around once it's in the partition. If you're modifying the partition field (in my case a timestamp) then it may mean you shouldn't be using a partition. If you're sure you want a partition on a mutable field, then at least make sure you periodically run:
"alter table shrink compact"
I came across this question as the top Google result when searching for ORA-14402. In my particular case I:
exported the rows as insert statements
updated the index key field and updated the ID field
inserted the rows as new rows.
You could then potentially delete the old rows if you have the need or leave them in the old partition.
Enable row movement with this syntex , it will solve the error :
alter table <table_name> enable row movement
FLASHBACK TABLE to a restore point fails when that restore point was created immediately after a table change. The below code only works if there is a sleep between certain steps.
SQL> DROP TABLE TEST_TABLE;
Table dropped.
SQL> CREATE TABLE TEST_TABLE AS SELECT 1 A FROM DUAL;
Table created.
SQL> ALTER TABLE TEST_TABLE ENABLE ROW MOVEMENT;
Table altered.
SQL> --Sleep required here to prevent error on flashback.
SQL> DROP RESTORE POINT TEST_RESTORE_POINT;
Restore point dropped.
SQL> CREATE RESTORE POINT TEST_RESTORE_POINT;
Restore point created.
SQL> FLASHBACK TABLE TEST_TABLE TO RESTORE POINT TEST_RESTORE_POINT;
FLASHBACK TABLE TEST_TABLE TO RESTORE POINT TEST_RESTORE_POINT
*
ERROR at line 1:
ORA-01466: unable to read data - table definition has changed
Why is a delay required and is there a way to eliminate it?
This oddity might be caused by SMON process which is responsible to keep track between SCNs and timestamps which flashback query relies upon. There is a mapping table SYS.SMON_SCN_TIME where every 5 minutes a new record is inserted SMON.
Internally during the FLASHBACK TABLE executes a command INSERT /*+ APPEND */ into SYS_TEMP_FBT SELECT /*+ FBTSCAN FULL(S) PARALLEL(S, DEFAULT) */ :1, :2, :3, rowid, SYS_FBT_INSDEL FROM "<schema>."TEST_TABLE" as of SCN :4 S (notice a table SYS_TEMP_FBT is created in the same schema) which uses this mapping.
Up to Oracle 10.2 you needed to wait up to whole 5 minutes to succeed with FLASHBACK query on a new/altered object. In 11.1 the TIM_SCN_MAP column was introduced to make the mapping more fine grained. Maximum of 100 mappings is stored in one value which makes roughly 3 seconds precision in timestamp to SCN mapping.
I tried many things but I don't think you can do anything about it but wait around 3 seconds to avoid the error because this is handled asynchronously by background process without any user control.
I have a query to delete some records from a table, but take too much time.
The table is use it in a stored procedure to match another table.
Every time that the SP is executed the table is truncated and filled with 2 or 3 millions of records depending of the received parameters.
The table doesn't have any FK or constraints
The query to delete the records that I am using is:
DELETE FROM TABLE1
WHERE (fecha,hora_ini,origen,destino,tipo,valor,rowsm1) IN (
SELECT fecha_t,hora_t,origen_t,destino_t,tipo,valor,id_t
FROM TABLE2)
I try to decrease the time in execute the query creating an index based in the same columns of the query
CREATE INDEX smb1 ON table1 (fecha,hora_ini,origen,destino,tipo,valor,rowsm1);
And the query take more time to execute.
How can improve the performance of this "DELETE" query.
UPDATE
EXPLAIN PLAN OUTPUT
DELETE TABLE1
TABLE ACCESS TABLE1
TABLE ACCESS FULL TABLE1
TABLE ACCESS FULL TABLE2
TABLE ACCESS FULL TABLE2
The index you created looks like a quite big index:
CREATE INDEX smb1
ON table1 (fecha,hora_ini,origen,destino,tipo,valor,rowsm1);
Sure, this depends on the amount of data but generally I would rather look for one or two selective columns - if possible.
Don't forget, that the index data has to be read as well and if it doesn't help to speed up the query, you even loose performance.
This might for instance happen, if the table is very small, because the database reads data block by block (I think it was about 8K). A small table can be read in one step - no need to use an index here.
Or, if more or less all records are selected. In this case the table has to be read anyway.
If you want to speed up the query you should create the same index (with a good selectivity) on table2. This way the EXPLAIN PLAN will look somewhat lie this:
DELETE STATEMENT
DELETE
NESTED LOOPS SEMI
INDEX FULL SCAN
INDEX RANGE SCAN
You can switch off logging and delete the rows,
Here is an example, you can do it 2 ways,
1.) Physically chaning the table to Nologging
2.) Using Nologging hint in the delete statement.
1.) First approach
both testemp and testemp2 are same tables with same data while testemp takes over a minute , testemp2 takes only 1 second
SQL> delete from testemp;
14336 rows deleted.
Elapsed: 00:01:04.12
SQL>
SQL>
SQL> alter table testemp2 nologging;
Table altered.
Elapsed: 00:00:02.86
SQL>
SQL> delete from testemp2;
14336 rows deleted.
Elapsed: 00:00:01.26
SQL>
The table needs to be put back to logging only when we physically change the table using "Alter" command, if you are using as hint not required please see the example below
2.) Second approach
SQL> set timing on;
SQL> delete from testemp2;
14336 rows deleted.
Elapsed: 00:00:01.51
Deleting data after reinserting same data into table now with nologging;
SQL> delete /*+NOLOGGING*/ from testemp2;
14336 rows deleted.
Elapsed: 00:00:00.28
SQL> select logging from user_Tables where table_name='TESTEMP2';
LOG
---
YES
I'm newbie to Oracle and database staff.
I had a huge Oracle 11g table of data with 200 million rows. I delete them all and kept only one. I read many articles on how to recover table space after deleting rows, etc but my table still takes a long time to be accessed (minutes).
Example:
select * from MyTable; Takes 0.02 seconds to return one record which is ok !
select * from MyTable where ID > 0; Takes more than 20 minutes to return one record.
(The ID field has an index)
I have successfully run the following commands:
alter table MyTable enable row movement;
alter table MyTable shrink space compact;
alter table MyTable deallocate unused;
But I still have the same issue.
Any ideas please ?