You'd certainly would know which packages are corrupted after wrapping; I'd take those packages, use the command line wrap utility and try it on those (source) files; also maybe compare them to the wrapped ones in your data dictionary:
https://docs.oracle.com/cd/B28359_01/appdev.111/b28370/wrap.htm#LNPLS01602 (be careful - the versions of the wrap utility plus the database version you are using dbms_ddl should match completely or otherwise you certainly will get differences; maybe simply use the wrap utility in the oracle home of your database server installation for testing purposes)
I am guessing the wrapper doesn't like some objects and refuses to wrap them; the command line utility is somewhat mute with errors as well, but at least it won't create garbage files when it can't wrap them, so you'd simply would need to check for source files which don't have the
wrapped keyword in their create command.
Hi, the reason for the wrapping from the dictionary is for a CI/CD implementation where we deploy from different sources, then we encrypt. Why not do it the other way around? Having a script / procedure / whatever which wraps packages in the data dictionary...I simply have a bad feeling about this (and your random corrupted package simply confirms this bad feeling).
Assuming you have version control in place, and assuming your deploy meachanism does (amongst others)
- check out from version control
- call sqlplus for each source file in directory X and run it against schema Y
- call stored procedure / script / whatever to wrap all sources in schema Y
you could do
- check out
- call the wrap utility for each source file in directory X (and let it output the wrapped destination files to directory Z)
- call sqlplus for each wrapped file in drectory Z and run it against schema Y
Then in your testing database there would never ever be a package in plain text if that is your concern, even at deploy time. Plus deployment would be faster as you'd have 50% less DDL statements at hand for creating database packages when deploying - you'd simply create your database packages already wrapped instead of first create them, then wrap them.
The wrap utility comes with a simple oracle client installation; you can wrap a package with a 11.2.0.x wrap utility and use this wrapped package in any 11.2.0.x database or higher if this is your concern.
cheers