I need to create a table from another table along with it's indexes and constraints in another schema in Oracle. I know about CTAS syntax but it doesn't take the indexes and constraints with it. Is there any way to do it?
Also is there any way to flashback procedure, triggers or package after dropping?
The simplest approach is to treat DDL statements like any other piece of application code, and keep them as scripts in a source control repository.
However, it's easy to be wise after the event. If you're working in an environment where the schema is a bit of a free fire zone there are various options.
The best thing is to use DBMS_METADATA to re-create the DDL statements. These can be saved as scripts, run in other schemas and - crucially - stored somewhere which gets backed-up, ideally source control.
To generate all the DDL for a table and its dependent objects is reasonably straightforward. The DBMS_METADATA functions return clobs, which is not ideal but simple enough to spool them out in SQL*Plus:
SQL> set long 10000
SQL> set heading off
SQL> spool create_tab_t23.sql
SQL> select dbms_metadata.get_ddl('TABLE', 'T23') from dual;
SQL> select dbms_metadata.get_dependent_ddl('INDEX', 'T23') from dual;
SQL> select dbms_metadata.get_dependent_ddl('TRIGGER', 'T23') from dual;
SQL> spool off
Having to specify the individual object types is a bit of a nausea. Fortunately most IDEs (Oracle SQL Developer, PLSQL Developer, TOAD, etc) provide handy right-click menu options to handle all this for us.
The easiest way to copy an entire Oracle table (structure, contents, indexes, constraintes, triggers, etc.) is to use Oracle's export and import utiilities (expdp and impdp). These are command-line utilities that you run on the database server using parameters that you provide. Or, you can use OEM (Oracle Enterprise Manager) to run these for you. Note that they they depend on having at least one "logical directory" defined where the "dump" file can get written to by export and read from by import.
This method work well when you want to copy a table from one schema to another, or from one database to another, and keep the same table name. If however your goal is to create a copy table in the same schema, but with a different name, then the process gets more complex. You can still use export, but then with import instead of doing the actual import directly, you have import create a text file for you that contains all of the SQL commands it finds in the export file. Then you edit that text file to change the index, constraint and trigger names that need to be changed plus change the table name in those commands to the new table_name (but do not change the table name in the "create table..." command). Then rename the existing table to something else and run just the "create table ..." command (with the original table_name) from the script file. Next, run import to get just the data. Then rename the new table to the name you want it to have and rename the original table to its original name. After that, you manually run the other SQL scripts from the script file. You don't want those triggers, constraints and indexes in place when you do the actual data import.
Related
The goal is to export an existing test Oracle database to SQL so that it can be run in a test pipeline using a Docker images's /container-entrypoint-initdb.d bootstrap. Currently we mount an oradata export, but it's opaque what the actual data is, hence the desire to use SQL so that it can be maintained via git.
I'm aware you can use the GUI Oracle SQL Developer Export Wizard to export a database to SQL.
Though how to do it via command line tools? I've tried many things like:
impdp test/test#XEPDB1 dumpfile=export.dmp directory=DUMP_DIR sqlfile=ddl.sql
And the best I can achieve is exporting the schema, however it is missing the actual data, e.g.
INSERT INTO currencies_countries (currency_id, country_id) VALUES ('EUR', 'CYP');
You have the exp which exports to a dump file that can be imported into another Oracle DB using imp. More recent are the xpdp and impdp.
See: https://oracle-base.com/articles/10g/oracle-data-pump-10g for instance.
What do you mean by "export to SQL"?
The sqldeveloper client tool has the possibility of exporting a table as SQL inserts, for instance. But to export that table by table would be quite an effort. Moreover, if you have millions of rows, those row by row inserts won't perform well.
Better write to tab-separated text files, which, in case of need may be imported into an Oracle DB using sqlldr, or may somehow be imported to some other kind database. Still, tab-separated files won't work well for tables having CLOB, XMLTYPE or some object-type columns.
You could write to a text file by spooling sqlplus output to a file having set linesize ling enough to fit the columns length, set pagesize 0 (no pages).
Or you could write to a file in an Oracle directory via a pl/sql program in which you use utl_file.
I want to have a backup of a specific table because a I want to change one of it's field, if changes don't work, apply the backup and restore the initial state. I'm using plsql developer
The simplest option is CTAS (Create Table As Select), i.e.
create table my_table_backup as select * From my_table;
Or, use Data Pump Export / Import utilities. Or, as it is just a single table, the original EXP / IMP utilities might also work.
Or, spool data into a CSV file and load it back using SQL*Loader (or external tables feature).
Quite a few options; I'd start with option 1 (CTAS).
With TOAD I know I can view the dependency (uses) graph of a stored procedure using the schema browser. And, the Oracle utility procedure deptree_fill can do something similar. What I want to do is script out all of the stored procedures, functions and table definition DLLs into a file that I can use to recreate those objects in another database. Is there a tool or an existing script for this purpose? My own searching has not found a solution. In my particular case the stored procedure uses a dozen other procedures, a few functions and twenty tables.
Edit 1
Maybe my original question was not clear. What I am looking for is something that will take the stored procedure I am interested in and script it and all of its dependency graph into one or more files.
The schema I am dealing with has hundreds of objects in it and the dependency graph has ~50 objects in it. So I'd rather not dig through large lists in TOAD or write an Oracle script myself if I can avoid it.
All sources can be extracted using the dbms_metadata package.
To get the source of a table:
select dbms_metadata.get_ddl('TABLE', 'SOME_TABLE')
from dual;
To get the source of a stored procedure:
select dbms_metadata.get_ddl('PROCEDURE', 'SOME_PROC')
from dual;
Using that you can create a SQL script that extracts everything and then spool the result to a file.
More details about the various functions in dbms_metadata can be found in the manual:
http://docs.oracle.com/cd/E11882_01/appdev.112/e25788/d_metada.htm#i1015856
Hmm, it is quite easy to find in google.
Get table DDL: How to get Oracle create table statement in SQL*Plus
Code of stored procedures can be found in table USER_SOURCE.
Also, for exporting schema to another DB you can use oracle utilities: http://docs.oracle.com/cd/B28359_01/server.111/b28319/exp_imp.htm#g1070082
In Toad see the Generate Schema Script window. You can get to it from the Database|Export menu. There are many options there to include/exclude what you want.
I want to create a table (lets say table_copy) which has same columns as other table (lets call it table_original) in Oracle database, so the query will be like this :
create table table_copy as (select * from table_original where 1=0);
This will create a table, but the constraints of table_original are not copied to table_copy, so what should be done in this case?
Only NOT NULL constraints are copied using Create Table As Syntax (CTAS). Others should be created manually.
You might however query data dictionary view to see the definitions of constraints and implement them on your new table using PL/SQL.
The other tool that might be helpful is Oracle Data Pump. You could import the table using REMAP_TABLE option specifying the name for the new table.
Use a database tool to extract the DDL needed for the constraints (SQL Developer does the job). Edit the resulting script to match the name of the new class.
Execute the script.
If you need to do this programmatically you can use a statement like this:
DBMS_METADATA.GET_DDL('TABLE','PERSON') from DUAL;
Our development team does all of their development on their local machines, databases included. When we make changes to schema's we save the SQL to a file that is then sent to the version control system (If there is a better practice for this I'd be open to hearing about that as well).
When working on SQL Server we'd wrap our updates around "if exists" statements to make them re-runnable. I am not working on an Oracle 10g project and I can't find any oracle functions that do the same thing. I was able to find this thread on dbaforums.org but the answer here seems a bit kludgy.
I am assuming this is for some sort of Automating the Build process and redoing the build from scratch if something fails.
As Shannon pointed out, PL/SQL objects such as Procedures, functions and Packages have the "create or replace" option, so a second recompile/re-run would be ok. Grants should be fine too.
As for Table creations and DDLs, you could take one of the following approaches.
1) Do not add any drop commands to the scripts and ask your development team to come up with the revert-script for the individual modules.
So for each create table that they add to the build, they will have an equivalent "DROP TABLE.." added to a script say."build_rollback.sql". If your build fails , you can run this script before running the build from scratch.
2)The second (and most frequently used approach I have seen) is to include the DROP table just before the create table statement and then Ignore the"Table or view does not exist" errors in the build log. Something like..
DROP TABLE EMP;
CREATE TABLE EMP (
.......
.......
);
The thread you posted has a major flaw. The most important one is that you always create tables incrementally. Eg, your database already has 100 tables and you are adding 5 more as part of this release. The script spools the DROP Create for all 100 tables and then executes it which does not make a lot of sense (unless you are building your database for the first time).
An SQL*Plus script will continue past errors unless otherwise configured to.
So you could have all of your scripts use :
DROP TABLE TABLE_1;
CREATE TABLE TABLE_1 (...
This is an option in PowerDesigner, I know.
Another choice would be to write a PL/SQL script which scrubs a schema, iterating over all existing tables, views, packages, procedures, functions, sequences, and synonyms in the schema, issuing the proper DDL statement to drop them.
I'd consider decomposing the SQL to create the database; one giant script containing everything for the schema sounds murderous to maintain in a shared environment. Dividing at a Schema / Object Type / Name level might be prudent, keeping fully dependent object types (like Tables and Indexes) together.