Should i drop schema or truncate tables before importing?

I have exported a dump of the whole schema form oracle database. I need to import this to another database with a different schema name but same tables. The only thing i am doing is this to bring data consistent with the other database.
Now Do i need to drop schema or do anything like that to avoid and redundancy or i can just go ahead and do the import? Please let me know how to do it. I would prefer not deleted any tables but truncate all the data if needed from about all 200 tables.
Thanks

For the places in your application where a Sequence is used to insert or set values in some tables, note that the sequence's current value may have been incremented if it has been used since the last import. If your truncate and re-import the tables, the tables may have the older (lower) values but the current sequence may be higher.
You would then have to "reset" the sequence best by dropping and recreating it.

Similar Messages

Truncate Table before Insert--Performance

HI All,
This post is in focus of special requirement where a table is truncated before inserting records in the table.
Now, when a table is truncated the High Water Mark(HWK) is reset to lowest memory allocated for table in tablespace. After this, would insert with append can boost the performance of the insert query?
In simple insert query, the oracle engine consults the free list to look for free spaces.
But in insert with apppend, the engine starts above the HWM. And the argument is when truncate has been executes on table, would the freelist be used in simple insert.
I just need to know if there are any benefits of using append insert on truncated table or simple insert would be same in term of performance with respect to insert with append.
Regards
Nits

Hi,
if you don't need the data truncate the table. There is no negativ impact whether you are using an conventional path or a direct path insert.
If you use append less redo is written for the table if the table is in NOLOGGING mode, but redo is written for all indexes. I would recommand to create a full backup after that (if needed), because your table will not be recoverable after that (no REDO Information).
Dim

IMPDP into schema with truncated tables, best way to do this?

Hello all,
I'm a bit of a noob witih datapump.
I've got a schema that I've truncated all tables. I have a full schema export I took awhile back, and I'm wanting to import this into the schema to basically 'reset' it.
First time run, I got the :
ORA-39151: Table "xyz.tablename" exists. All dependent metadata and data will be skipped due to table_exists_action of skip
I've been reading through, and see suggestions to add to the par file:
CONTENT=DATA_ONLY TABLE_EXISTS_ACTION=APPEND
And I've seen others use the option for:
table_exists_action=replace
I'm wondering if I could get suggestions best approach to use...I basically want to put the data back into the tables, and have the indexes rebuilt....what is the best course of action here?
Thank you in advance,
cayenne

If all you want is to reload the data, then
impdp user/password ... content=data_only table_exists_action=append
This will only load the data into the existing tables and it will append the data to those tables. If the table definitions may have changed, then you would remove the content=data_only and use table_exists_action=replace.
If you need to load dependent objects like indexes, constraints, etc, then don't do content=data_only and use table_exists_action=replace.
Hope this helps.
Dean

Schema-based xmltype table

Below mentioned is the schema-based xmltype table
CREATE TABLE BRSK.MEDV_brpubdoc_tab OF XMLType
XMLSCHEMA "http://xmlns.oracle.com/xdb/schemas/BRSK/www.medversation.com/brpubdoc/brpubdoc.xsd"
ELEMENT "brpubdoc"
TABLESPACE BRSK_M;
when ever delete the old schema and register the new schema should i drop the previous xmltype table and create the new one?If this is the case then we will be losing the previous xml contents.Is there is a way to avoid drop and creation on xmltype table on schema delete and schema registration.Please help me out on this.

I hava gone through the below mentioned link http://download-east.oracle.com/docs/cd/B12037_01/appdev.101/b10790/xdb07evo.htm which states In prior releases an XML schema, once registered with Oracle XML DB at a particular URL, could not be modified or evolved because there may be XMLType tables that depend on the XML schema. There was no standard procedure for schema evolution. This release supports XML schema evolution by providing a PL/SQL procedure CopyEvolve() a part of the DBMS_XMLSCHEMA package. CopyEvolve() involves copying existing instance documents to temporary tables, dropping and re-registering the XML schema, and copying the instance documents to the new XMLType tables.So i think schema evolution works in 10g only

Problem in truncate/drop partitions in a table having nested table columns.

Hi,
I have a table that has 2 columns of type nested table. Now in the purge process, when I try to truncate or drop a partition from this table, I get error that I can't do this (because table has nested tables). Can anybody help me telling how I will be able to truncate/drop partition from this table? IF I change column types from nested table to varray type, will it help?
Also, is there any short method of moving existing data from a nested table column to a varray column (having same fields as nested table)?
Thanks in advance.

>
I have a table that has 2 columns of type nested table. Now in the purge process, when I try to truncate or drop a partition from this table, I get error that I can't do this (because table has nested tables). Can anybody help me telling how I will be able to truncate/drop partition from this table?
>
Unfortunately you can't do those operations when a table has a nested table column. No truncate, no drop, no exchange partition at the partition level.
A nested table column is stored as a separate table and acts like a 'child' table with foreign keys to the 'parent' table. It is these 'foreign keys' that prevent the truncation (just like normal foreign keys prevent truncating partions and must be disabled first) but there is no mechanism to 'disable' them.
Just one excellent example (there are many others) of why you should NOT use object columns at all.
>
IF I change column types from nested table to varray type, will it help?
>
Yes but I STRONGLY suggest you take this opportunity to change your data model to a standard relational one and put the 'child' (nested table) data into its own table with a foreign key to the parent. You can create a view on the two tables that can make data appear as if you have a nested table type if you want.
Assuming that you are going to ignore the above advice just create a new VARRAY type and a table with that type as a column. Remember VARRAYs are defined with a maximum size. So the number of nested table records needs to be within the capacity of the VARRAY type for the data to fit.
>
Also, is there any short method of moving existing data from a nested table column to a varray column (having same fields as nested table)?
>
Sure - just CAST the nested table to the VARRAY type. Here is code for a VARRAY type and a new table that shows how to do it.
-- new array type
CREATE OR REPLACE TYPE ARRAY_T AS VARRAY(10) OF VARCHAR2(64)
-- new table using new array type - NOTE there is no nested table storage clause - arrays stored inline
CREATE TABLE partitioned_table_array
     ( ID_ INT,
      arra_col ARRAY_T )
     PARTITION BY RANGE (ID_)
     ( PARTITION p1 VALUES LESS THAN (40)
     , PARTITION p2 VALUES LESS THAN(80)
     , PARTITION p3 VALUES LESS THAN(100)
-- insert the data from the original table converting the nested table data to the varray type
INSERT INTO PARTITIONED_TABLE_ARRAY
SELECT ID_, CAST(NESTED_COL AS ARRAY_T) FROM PARTITIONED_TABLENaturally since there is no more nested table storage you can truncate or drop partitions in the above table
alter table partitioned_table_array truncate partition p1
alter table partitioned_table_array drop partition p1

TRUNCATE TABLE NOT WORKING AFTER DROPPING CONSTRAINTS

Hi,
I have a table with a foreign key constraint. I know you can't truncate tables when there are foreign key constraints. So I drop the constraints before running the TRUNCATE TABLE command. But SQL Server is still stating there are foreign key constraints
even after they have just been dropped.
When I use SQL Server Management Studio to generate a drop & create script on this table or any other table with an FK consttaint, the generated script fails stating that there are still foreign key constraints??
I have the same problem for every table that has FK constraints, for those without FK, TRUNCATE table works without issues.
The end goal is to reset the identity value of the primary key. Since DBCC does not work on Azure, TRUNCATE TABLE is the only way left, especially if you can't even drop and recreate tables with FK constraints.
What am I missing here?
Peter

Hi,
Thanks for posting here.
TRUNCATE TABLE is similar to the DELETE statement with no WHERE clause; however, TRUNCATE TABLE is faster and uses fewer system and transaction log resources.
TRUNCATE TABLE removes all rows from a table, but the table structure and its columns, constraints, indexes, and so on remain. To remove the table definition in addition to its data, use the DROP TABLE statement.
If the table contains an identity column, the counter for that column is reset to the seed value defined for the column. If no seed was defined, the default value 1 is used. To retain the identity counter, use DELETE instead.
Restrictions
You cannot use TRUNCATE TABLE on tables that:
•Are referenced by a FOREIGN KEY constraint. (You can truncate a table that has a foreign key that references itself.)
•Participate in an indexed view.
•Are published by using transactional replication or merge replication.
For tables with one or more of these characteristics, use the DELETE statement instead.
TRUNCATE TABLE cannot activate a trigger because the operation does not log individual row deletions. For more information, see CREATE TRIGGER (Transact-SQL).
Truncating Large Tables
Microsoft SQL Server has the ability to drop or truncate tables that have more than 128 extents without holding simultaneous locks on all the extents required for the drop.
Permissions--------------------------------------------------------------------------------
The minimum permission required is ALTER on table_name. TRUNCATE TABLE permissions default to the table owner, members of the sysadmin fixed server role, and the db_owner and db_ddladmin fixed database roles, and are not transferable. However, you
can incorporate the TRUNCATE TABLE statement within a module, such as a stored procedure, and grant appropriate permissions to the module using the EXECUTE AS clause.
You cannot truncate a table which has an FK constraint on it.
Typically my process for this is:
Drop the constraints
Trunc the table
Recreate the constraints.
Hope this helps you.
Girish Prajwal

Free Connections to a table before truncate

Hi All,
I need to kill all connections to table before truncating table in production environment.Is there any script for the same?
Regards
Rahul

You don't really have a connection to a table, but processes take out locks on rows in the table as they access the rows. Or on table if they scan many rows.
It would be possible to query sys.dm_tran_locks to get the processes that hold locks, but you cannot really prevent new processes to come in.
A more lazy method is to issue your "TRUNCATE TABLE" in one query window, and then run sp_who in another. You process will be reported as blocked by other process, so you kill that process. Then you run sp_who again, kill that guy and so on.
Then again, killing processes in a production environment? It's not entirely appetising.
Erland Sommarskog, SQL Server MVP, [email protected]

Truncate table that has 2 billion rows

Hi,
Our DB is 11g and approximately any idea howmuch time it takes and do we need to rebuild indexes after truncate?

>
Our DB is 11g and approximately any idea howmuch time it takes and do we need to rebuild indexes after truncate?
>
Before you do that - do you plan to reload the table with a similar amount of data?
If so then you might want to use the REUSE STORAGE clause so that Oracle doesn't have to deallocate and then immediately reallocate the storage.
See the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_10007.htm
>
REUSE STORAGE Specify REUSE STORAGE to retain the space from the deleted rows allocated to the table. Storage values are not reset to the values when the table or cluster was created. This space can subsequently be used only by new data in the table or cluster resulting from insert or update operations. This clause leaves storage parameters at their current settings.
>
If you plan to do a large reload you should consider dropping or disabling the indexes and then adding/rebuilding them after the data load.

Release of space after delete/truncate table

Hello,
How does release of space after delete/truncate table works? Is the space used before deletion released once delete is complete or not? Will I see the space occupied by deleted table as free in dba_segments or will I need to reorganize the table (drop and recreate again?). Reason why I am asking is that I can see table with 0 rows, but in dba_segment I can see it is occupying few gigabytes....
Thank you

Here is a little illustration for you;
SQL> conn ogan/password
Connected.
SQL> create table ogan_deneme as select * from all_objects;
Table created.
SQL> select count(*) from ogan_deneme;
COUNT(*)
    228470
SQL> set line 1000
SQL> set pagesize 1000
SQL> select * from dba_segments where owner='OGAN';
OWNER    SEGMENT_NAME        PARTITION_NAME           SEGMENT_TYPE       TABLESPACE_NAME                HEADER_FILE HEADER_BLOCK      BYTES     BLOCKS    EXTENTS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_
OGAN      OGAN_DENEME          TABLE              SYSTEM                                 854       319981   *30408704*       *1856*         *44*          65536                       1 2147483645                       1               1          854 DEFAULT
SQL> truncate table ogan_deneme;
Table truncated.
SQL> select * from dba_segments where owner='OGAN';
OWNER    SEGMENT_NAME        PARTITION_NAME           SEGMENT_TYPE       TABLESPACE_NAME                HEADER_FILE HEADER_BLOCK      BYTES     BLOCKS    EXTENTS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_
OGAN      OGAN_DENEME           TABLE              SYSTEM                                 854       319981      *65536*          *4*          *1*          65536                       1 2147483645                       1               1          854 DEFAULT
SQL>Hope it Helps,
Ogan

Truncate TABLE PSA table-index part

Dear all,
I have a doubt about the truncate action on BW of PSA table.
To speed the activity and empty some tablespace I have truncated for example the PSA /BIC/B0000025000 and all table and index parts have emptied, so, on the contrary of disk space, the table part and index part from 00001 to 00050 for example are no longer used and the next uploads creates partition 00051.
The question is: I must drop all index and table part previously emptied?
If yes a must keep in mind some indications?
I could have some problem to leave this table and index part empty, for example about performance or inconsistence?
There is some contraindication to truncate PSA?
Can i use program 'RSAR_CLEANUP_PSA_DIRECTORY' to delete its?
Thanks for your help.
Best Regards
Daniele

Hi Kaushal,
thanks for your answer.
I have executed program mentioned in oss note 733371.
After the execution of RSAR_PSA_CLEANUP_DIRECTORY
some errors have found:
in the head of log there are this two entries:
Fatal error occured, DO NOT USE correct option
For errors 'wrongly present in partition' refer to NOTE 849857 / 992248
the rest of log this kind of errors:
Request : ODSR_47KKTL3NMVNZPGY17C4POEYAV missed in partition 0015
The oss note 849857 is for release lower of mine, the note 992248 is for my release, its talks about a program 'SAP_PSA_ZEROCORRECT' imported automatically with SP 11, i have level 13 os SP BI but i didn't find that program,
do you have some idea about that?
After execution of report RSAR_PSA_CLEANUP_DEFINITION (only check)
I have this error:
No DDIC Table Exists for PSA: ZEDS_NOT_T_BA Vrs. 000
There Is No Active DDIC Table: /BIC/B0000852000
Do you think that if i run RSAR_PSA_CLEANUP_DEFINITION with repair object i can resolve all my problem visualized for report RSAR_PSA_CLEANUP_DIRECTORY either? Or before in must execute RSAR_PSA_CLEANUP_DIRECTORY whit repair option?
Thanks for your help
Ciao

Schema level and table level supplemental logging

Hello,
I'm setting up bi- directional DML replication between two oracle databases. I have enabled supplemental logging database level by running this command-
SQL>alter database add supplemental log data (primary key) columns;
Database altered.
SQL> select SUPPLEMENTAL_LOG_DATA_MIN, SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI from v$database;
SUPPLEME SUP SUP
IMPLICIT YES NO
-My question is should I enable supplemental logging table level also(for DML replication only)? should I run the below command also?
GGSCI (db1) 1> DBLOGIN USERID ggs_admin, PASSWORD ggs_admin
Successfully logged into database.
GGSCI (db1) 2> ADD TRANDATA schema.<table-name>
what is the deference between schema level and table level supplemental logging?

For Oracle, ADD TRANDATA by default enables table-level supplemental logging. The supplemental log group includes one of the following sets of columns, in the listed order of priority, depending on what is defined on the table:
1. Primary key
2. First unique key alphanumerically with no virtual columns, no UDTs, no functionbased
columns, and no nullable columns
3. First unique key alphanumerically with no virtual columns, no UDTs, or no functionbased
columns, but can include nullable columns
4. If none of the preceding key types exist (even though there might be other types of keys
defined on the table) Oracle GoldenGate constructs a pseudo key of all columns that
the database allows to be used in a unique key, excluding virtual columns, UDTs,
function-based columns, and any columns that are explicitly excluded from the Oracle
GoldenGate configuration.
The command issues an ALTER TABLE command with an ADD SUPPLEMENTAL LOG DATA clause that
is appropriate for the type of unique constraint (or lack of one) that is defined for the table.
When to use ADD TRANDATA for an Oracle source database
Use ADD TRANDATA only if you are not using the Oracle GoldenGate DDL replication feature.
If you are using the Oracle GoldenGate DDL replication feature, use the ADD SCHEMATRANDATA command to log the required supplemental data. It is possible to use ADD
TRANDATA when DDL support is enabled, but only if you can guarantee one of the following:
● You can stop DML activity on any and all tables before users or applications perform DDL on them.
● You cannot stop DML activity before the DDL occurs, but you can guarantee that:
❍ There is no possibility that users or applications will issue DDL that adds new tables whose names satisfy an explicit or wildcarded specification in a TABLE or MAP
statement.
❍ There is no possibility that users or applications will issue DDL that changes the key definitions of any tables that are already in the Oracle GoldenGate configuration.
ADD SCHEMATRANDATA ensures replication continuity should DML ever occur on an object for which DDL has just been performed.
You can use ADD TRANDATA even when using ADD SCHEMATRANDATA if you need to use the COLS option to log any non-key columns, such as those needed for FILTER statements and KEYCOLS clauses in the TABLE and MAP parameters.
Additional requirements when using ADD TRANDATA
Besides table-level logging, minimal supplemental logging must be enabled at the database level in order for Oracle GoldenGate to process updates to primary keys and
chained rows. This must be done through the database interface, not through Oracle GoldenGate. You can enable minimal supplemental logging by issuing the following DDL
statement:
SQL> alter database add supplemental log data;
To verify that supplemental logging is enabled at the database level, issue the following statement:
SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;
The output of the query must be YES or IMPLICIT. LOG_DATA_MIN must be explicitly set, because it is not enabled automatically when other LOG_DATA options are set.
If you required more details refer Oracle® GoldenGate Windows and UNIX Reference Guide 11g Release 2 (11.2.1.0.0)

Internal Behaviour of Truncate Table Command in Oracle Database

Hi,
Can anyone let me know the internal behaviour of Truncate Table Command in Oracle Database?
Thanks,
Harshad.

Hi Tuhinshoor,
I know the functioning of Truncate Command.
But, I needed to know whether it drops the table before recreating it, maintaining all the indexes and constraints intact??
Thanks,
Harshad.

Interrupted TRUNCATE TABLE command

Hello,
I've made very dangerous mistake today: TRUNCATE TABLE on production database. :-(
But in several seconds (2 or 3), I managed to break the operation (Before the execution ended).
It was quite a big table, now (after the accident) there are more then 32 million records.
We need to know, are there any records deleted?
We have no proper backup, to compare the records with it.
And I could not find any in-depth description of how TRUNCATE works.
Please can you:
1. Tell, about any method to check if there are deleted records?
2. Link, to any resource, where I can read in details, about how TRUNCATE TABLE works.
Thanks, in advance, for help

My understanding is that the TRUNCATE TABLE table statement is atomic. It either fails or succeeds. Truncates all rows or no rows at all. Therefore if you interrupt a TRUNCATE TABLE statement your table should remain in its original state.
This can be shown below:
SQL > CREATE TABLE TEST AS SELECT * FROM ALL_OBJECTS;
Table created.
SQL > INSERT INTO TEST SELECT * FROM TEST;
12421 rows created.
SQL > INSERT INTO TEST SELECT * FROM TEST;
24842 rows created.
SQL > INSERT INTO TEST SELECT * FROM TEST;
49684 rows created.
SQL > INSERT INTO TEST SELECT * FROM TEST;
99368 rows created.
SQL > INSERT INTO TEST SELECT * FROM TEST;
198736 rows created.
SQL > INSERT INTO TEST SELECT * FROM TEST;
397472 rows created.
SQL > INSERT INTO TEST SELECT * FROM TEST;
794944 rows created.
SQL > INSERT INTO TEST SELECT * FROM TEST;
1589888 rows created.
SQL > SELECT COUNT(*) FROM TEST;
COUNT(*)
3179776
SQL > TRUNCATE TABLE TEST;
^C
H:\>sqlplus /@testdb
SQL*Plus: Release 10.2.0.4.0 - Production on Mon Aug 3 08:20:11 2009
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Enter password:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL > SELECT COUNT(*) FROM TEST;
COUNT(*)
3179776HTH!

Export data from database table before database migration

Hello,
We are planning to migrate our SAP ERP 6 Ehp4/NW7.01 from Oracle 11.2 to IBM DB2 v. 9.7 database. During test migrations I have established that we spend a lot of time for one particular table (COEP). Because we donu2019t have possibility to archive this table before migration I have an idea to export data from previous years from this table to the file system (using an ABAP report), delete those data from table before migration and then after migration, import back to the database from the file system.
Does anybody have any concerns or suggestions about this idea?
Thank you for your answers
Andrej

Hello Andrej,
I strongly do not recommend to do so.
I am not sure whether technically this could work at all..
Even it if would work .. In order to really save time, the export and the import would have to be a dirty one (meaning the system is operational and in production). With this there is a high risk to produce inconsistencies on this table. And you most likely will receive no support if something unforeseen happens and you end with problems.
Also your approach (if it should work at all) , would have to be tested thoroughly by you , also protecting the table from any changes.
I do not believe that this can save any effort compared to implementing advanced migration techniques like table splitting.
On top, you would go high risk to end with an unsupported system, with not using official migration procedures
Hans-Juergen

Problem with Drag & Drop and multiselection in tables

Hi,
we have a problem concerning drag and drop and multiselection in tables. It is not possible to drag a multiselection of table rows, as the selection event is recognized or handled before the drag event. So before the drag starts, the selection will be changed and only a single row is selected at the position where you started the drag with a mouse click.
There was also a java bug with the id 4521075 regarding this problem a couple of years ago. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4521075.
This bug has been resolved but in our application we have not enabled drag by setting setDragEnabled(true) on the table as we have an own implementation of a DragSource (which is the table component), and a DragGestureRecognizer to control mimetype and data to be dragged.
So my question is: Is there any solution for this case without calling setDragEnabled(true) on the table? Or is it possible to enable drag on the table and override some method where the drag recognition happens and the transferable object is created?
Thanks,

Thanks for reply,
Steps to reproduce the problem:
1) user clicks the ascending sorting icon in the table(the button get disabled after sorting the table).
2) After sorting user drag and drop some row over another row.
3) Now the table is no longer sorted.
4) If user again wants to sort the table now, he cannot do it because the sorting button is still disabled.
So I want the user to sort the table again, without refreshing the page
Thanks and Regards,
Tarun

Should i drop schema or truncate tables before importing?

Similar Messages

Maybe you are looking for