I need to change a column type in more than 200 tables I am following the next recipe:
Disable all foreign constraints if the column is referenced by any FK
Store columns in varray and Drop primary key if the column is part of a PK
Create a temporal new column in the table with the same type
Update the temporal new column with original values
Delete values from original column
Change column type of original column
Update original column with temporal column values
Restore primary key if applied
Enable FK if applied
I am having some issues with the following cases
. When a primary key is compound (Multiple columns)
. I need to store the original FK and PK signature to allow me to restore them after the change
------- My ideas --------
Backup all_constraints and all_cons_columns records in a temporary table and after changing the column type resstoring the constraints info.
Keep with the same idea of storing the FK and PK signature to restore them after changing the column type
¿ Any suggestions ? would be appreaciate it, thx!!
You could try the old CTAS then rename method:
basically:
create new table as select c1,c1,c3 ... from old table (include data
type transformation here;
establish any indexes, constraints ...
drop old table (may need to disable donstraints first)
rename new table to old table
Related
Working on hive table, where I need to change column name as below, its working as expected and changing column name but underline value of this column getting NULL.
ALTER TABLE db.tbl CHANGE hdfs_loaddate hdfs_load_date String;
Here changed column name is hdfs_load_date and values are getting NULL after renaming column name.
Does any one have idea to fix this. Thanks in advance!!
#Ajay_SK Referencing this article: Hive Alter table change Column Name
There is a comment:
Note that the column change will not change any underlying data if it is a parquet table. That is, if you have data in the table already, renaming a column will not make the data in that column accessible under the new name: select a from test_change; 1 alter table test_change change a a1 int; select a1 from test_change; null
He is specific to parquet, but the scenario you describe is similar where you have successfully changed the name, but hive still thinks the original data is in the original key.
A better approach to solve your issue, would be to create a new table of the schema you want with column name change. Then perform an Insert INTO new table select FROM * old table.
I read that we cannot create a primary key on a column in a Hive table. But I saw the below DDL in some other place and executed it. It worked without any problem.
create table prim(id int, name char(30))
TBLPROPERTIES("PRIMARY KEY"="id");
After this I executed "describe formatted prim" and got to see that a key is created on the column ID
Table Parameters:
PRIMARY KEY id
I inserted two records with same ID number into the table.
insert into prim values(1,'ABCD');
insert into prim values(2,'EFGH');
Both the records were inserted into the table. What baffles me is that we cannot give the PRIMARY KEY in the create statement which I can understand, but when given in TBLPROPERTIES("PRIMARY KEY"="id") how different is it to the primary key in RDBMS.
PRIMARY KEY in TBLPROPERTIES is for metadata reference to preserve column significance. It does not apply any constrain on that column. This can be used as a reference from design perspective.
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 have a table with Col1 and Col2 as a composite primary key pk_composit_key and a unique index that was automatically created for the constraint.
I then altered the table to add new column Col3.
I dropped the pk_composit_key constraint:
ALTER TABLE table_name DROP CONSTRAINT pk_composit_key;
Now, When I tried to insert records I got ORA-00001: unique constraint pk_composit_key violated.
Why am I getting that error?
When the key was dropped why wasn't the unique index dropped automatically?
You mentioned exporting and importing the schema, and if that happened in the environment that showed this behaviour it would explain what you're seeing; at least if you used legacy imp rather than the data pump impdp.
The original import documentation states the order objects are imported:
Table objects are imported as they are read from the export dump file. The dump file contains objects in the following order:
Type definitions
Table definitions
Table data
Table indexes
Integrity constraints, views, procedures, and triggers
Bitmap, function-based, and domain indexes
So the unique index would have been imported, then the constraint would have been created.
When you drop a primary key constraint:
If the primary key was created using an existing index, then the index is not dropped.
If the primary key was created using a system-generated index, then the index is dropped.
Because of the import order, the constraint is using an existing index,so the first bullet applies; and the index is retained when the constraint is dropped.
You can use the drop index clause to drop the index even if it wasn't created automatically:
ALTER TABLE table_name DROP CONSTRAINT pk_composit_key DROP INDEX;
See also My Oracle Support note 370633.1; and 1455492.1 suggests similar behaviour will occur with data pump import as well. I'm not aware of any way to check if an index is associated with a constraint at this level; there is no difference in the dba_constraints or dba_indexes views when you create the index manually or automatically. Including drop index will make it consistent though.
It depends on how unique index was created...below are the various ways and behaviour
1) first create unique index (on the column for which primary key to be defined) and then add the primary key constraint. In this situation your DDL to add the primary key will utilize the existing unique index. So when you drop the primary key it will not drop the index but only primary key. ==> this is your situation I guess...
2) While creating the table you define the primary key OR when you add the primary key when there was no existing unique index for the column(s) on which primary key to be defined, so system will create a unique index and use it for primary key. So in this case when you drop the primary key the unique index will also get dropped.
How can I change DATA TYPE of a column from number to varchar2 without deleting the table data?
You can't.
You can, however, create a new column with the new data type, migrate the data, drop the old column, and rename the new column. Something like
ALTER TABLE table_name
ADD( new_column_name varchar2(10) );
UPDATE table_name
SET new_column_name = to_char(old_column_name, <<some format>>);
ALTER TABLE table_name
DROP COLUMN old_column_name;
ALTER TABLE table_name
RENAME COLUMN new_column_name TO old_coulumn_name;
If you have code that depends on the position of the column in the table (which you really shouldn't have), you could rename the table and create a view on the table with the original name of the table that exposes the columns in the order your code expects until you can fix that buggy code.
You have to first deal with the existing rows before you modify the column DATA TYPE.
You could do the following steps:
Add the new column with a new name.
Update the new column from old column.
Drop the old column.
Rename the new column with the old column name.
For example,
alter table t add (col_new varchar2(50));
update t set col_new = to_char(col_old);
alter table t drop column col_old cascade constraints;
alter table t rename column col_new to col_old;
Make sure you re-create any required indexes which you had.
You could also try the CTAS approach, i.e. create table as select. But, the above is safe and preferrable.
The most efficient way is probably to do a CREATE TABLE ... AS SELECT
(CTAS)
alter table table_name modify (column_name VARCHAR2(255));
Since we can't change data type of a column with values, the approach that I was followed as below,
Say the column name you want to change type is 'A' and this can be achieved with SQL developer.
First sort table data by other column (ex: datetime).
Next copy the values of column 'A' and paste to excel file.
Delete values of the column 'A' an commit.
Change the data type and commit.
Again sort table data by previously used column (ex: datetime).
Then paste copied data from excel and commit.