So you’ve been working on your data model, and you’re wondering how far ‘out of whack’ it is with the production or development database instance. Sometimes folks manage to compile changes into the database, bypassing your design process and rules.
If you’re wondering how to compare 2 models instead of your model with the database, read this.
So your question is basically, show me what’s different. You just need to decide what version of the ‘truth’ to adhere to:
- the database
- the model
You need to make this call as the comparison results include DDL scripts to bring the system into alignment.
Which way are you going?
But Wait, Those Buttons Are Greyed Out For Me!
To compare your model with the data dictionary, we need to know where that data dictionary is. If you add the model objects from a data dictionary, the connection information is ‘known’ to the model. If you look at one of your model object’s properties, you can see if it’s ‘tied’ to a database:
This table is ‘linked’ to a SQL Developer connection name – which allows the modeler to do the compare
Filtering and Selecting Your Results
The comparison dialog will come back with your results. You can review the differences and ‘approve’ the findings by checking those items in the tree. Key things to check are the ‘Tables that will be recreated’ and the ‘Options’ panels. Some object alters might not be possible without dropping and re-creating the table. Additionally, the ‘options’ panel allows you to decide exactly what properties to compare or not. This will have a dramatic impact on the type of DDL scripts the compare will generate.
A model compare/synch report
Applying the Scripts
There’s no ‘go make it happen’ button in the modeler. You’ll have to take the generated script, test it, tweak it, and approve it. Then you’ll need to run it against your database either via SQL*Plus or SQL Developer. Looking for a ‘apply’ button that will automatically execute the script against your database? Share your thoughts in our Exchange with your enhancement requests. Personally, I think this would be ‘dangerous,’ but I see that many other modeling tools offer this feature, so maybe I’m just too paranoid.
But I Only Want to Compare a Few Things, Not Everything!
Ok, so your model is huge, and you don’t care about ‘everything’ right now. You have three levels of compare ‘depth’ to choose from:
- Compare everything
- Compare just the SubView
- Compare just selected objects
You already know how to compare ‘everything’ – just use the main toolbar ‘Synchronize’ buttons.
Compare Just the SubView
SubViews are great. They allow you to break your model into one or more ‘mini’ models. If you do a data dictionary import from multiple schemas, SQL Developer will automatically generate a SubView for each schema. If you only wanted to synchronize/compare just one schema in your model, then the SubView compare would be the easiest way to go.
To kick off the synchronize, go into the subview, and right-click in the subivew diagram.
It’s a big context menu, just skip down to the bottom!
Compare Just Selected Model Objects
Just what it sounds like, if you want a quick-and-dirty compare, just select or multi-select the object(s) in the diagram, right click and ‘Synchronize…’
Summary
Again, don’t forget to check, check, and check again your options. Then make sure to test your scripts before you just run them against your DEVELOPMENT or TEST databases. I’m not even going to mention PRODUCTION, because you already know better.
One last word about options – you can say in the preferences what pieces of the PHYSICAL model properties to apply in your compares. By default we only take in the tablespaces and sequences from that level. So if you’re wondering why your synonyms or PL/SQL objects aren’t being compared and ‘synched’, then go to the preferences and toggle them on.
What all do you want compared from the physical level?