Using Schema Compare for Oracle to create deployment script

We have a large (2000+) set of scripts used to deploy out database code. Does anyone know whether there is a tool that can be used to create a single dep开发者_开发知识库loyment script that conforms to correct dependency order?

I understand that this can be done using Redgate's SQL Compare, however that's great if you have SQL Server. From the limited information on the Schema Compare for Oracle tool it doesn't appear to have this functionality.

---

I'd go with the following order (broadly based on the order that objects are extracted with an EXPDP) :

• SYNONYM
• TYPE (table column may depend on user defined type)
• DB_LINK
• SEQUENCE
• TABLE-TABLE
• TABLE-GRANT
• TABLE-INDEX
• TABLE-CONSTRAINT (you may want PK constraint enforced by an existing index)
• TABLE-COMMENTS
• PACKAGE
• FUNCTION
• PROCEDURE
• VIEW
• TABLE-REF CONSTRAINTS
• TABLE-TRIGGER
• TABLE-INDEX (FUNCTIONAL)
• MATERIALIZED VIEW
• MATERIALIZED VIEW LOG
• JOB

---

I'd create a script to kick off your scripts in the proper order, depending on how they're implemented.

• Tables / Sequences
• Views / Types
  • (generally with the force option so they're created if there's a generation order issue or dependency to "code" types or other views and types)
• Packages / Procedures / Functions / Triggers
  • (if these are created out of dependency order, they'll still create, but be invalid)
• Foreign Key constraints

Kick off rdbms/admin/utlrp to recompile invalid objects when you're done to recompile invalid objects.

---

I'm not sure I've fully understood your problem, but you might want to try the following:

1. Run your current scripts to create a database
2. Create a blank schema
3. Use Red Gate's Schema Compare to compare your database with the blank schema
4. Save the script (which should be in dependency order)

---

---

The following is a general guideline for the order in which to run the installation scripts for different types of database objects:

Package specifications

Tables (with constraints and indexes) in proper order

Sequences (because they are most often used by triggers)

Triggers

Synonyms

Views (because they may reference functions, procedures, or synonyms)

Package bodies

Data (optionally disabling all constraints before loading the data and re-enabling them afterwards)

Package specifications are listed first because they will always be valid and other objects might refer to them. Package bodies should be the last object type created because they will probably refer to other object types. Because of dependency issues, you are encouraged to put functions and procedures into packages.