Following is my oracle version
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
I was trying to alter a table to add a column but since it took long time, i cancelled it.
After sometime, i started seeing errors in all packages and views that referenced the unit.
Error message is
PLS-907: cannot load library unit (table name)
Googling on this error does not give much information. In one place, i saw that below command will help but it seems to me as very risky command
alter system flush shared_pool
Can anyone help me with the reason and solution to this?
Thanks,
Jeevan
it happens because of DB links are dropped and recreated for connections so just recompiling the package will resolve this and some times it automatically recompile it .
While changing the length of a varchar2 may resolve a problem in one procedure, for example, it can cause other objects to go invalid. Typically the solution for resolving the invalid object is just recompiling. Before recompiling - parameters, variables, etc need to be checked to ensure they accommodate for the change.
Related
a little background, I really don't know any technical terms from Oracle. My company have a pre built machine and I'm trying not having to go there backup my files and lose a day of job because I cant.
Recently I'm learning how to use Oracle Designer (6i) to build a diagram and later a table so I can request it to be created... While using the software it requested to install some file for the repository... after doing it, It screwed up every Oracle product I was using... I couldn't connect to PLSQL or even the designer...
After fixing some registry to point to the right TNSNAME and manually adjusting PLSQL, I managed to access both. The problem in hand is in oracle Designer at the "Designer Editor", when I right click a table and select generate, the message bellow shows up
Message
-------
CDD-23564: The file "C:\ORACLE\DSG6I\BIN\cds61.dll" could not be loaded or does not exist.
Cause
-----
The specified file or one its dependent files could not be loaded.
This may be because a file has not been installed, or is not
correctly defined in the system registry.
As an example dependency, the Forms Generator files require the
Form Builder files installed as part of Developer.
Action
------
Check the registry settings for the location of the required
file. Also check the product and any required dependencies
e.g.Developer have been installed correctly.
If necessary, try reinstalling.
The dll mentioned IS and EXISTS on the mentioned folder.
Considering I don't have the Oracle Developer 6i intaller, what can I do? What registry entry should I update?
Designer 6 is long out of support. Oracle has a free tool, SQL Developer Data Model, which does not break.
Even Designer 9i was flaky and would crash at random intervals and poke along with larger schemas. Anything over hundred tables could take days to edit. Ah, good times...
I managed to fix the problem by copying and replacing the whole ORACLE_HOME\DSG6I folder (in my case c:\Oracle\DSG6I, for those confused in terms like me) and the oracle system registry (regedit > HKEY_LOCAL_MACHINE\SOFTWARE\Oracle) from a coworker machine!
We are looking to introduce odac into our application but I am running into a number of issues and I can't seem to find any solutions that fix our issues.
We are using an oracle database and trying to use ODAC 12c Release 1 (12.1.0.1.0) with Oracle Developer Tools for Visual Studio.
In our model we would like to have multiple schemas so we can perform cross schema queries. The schemas which we select in the filter for the database connection appear when we are creating the model. However when we try to update our model from the database only the default schema is visible. Sometimes this can be fixed by opening the relevant part of the database in Server Explorer in Visual Studio but this doesn't always work. This fix never works after we add multiple connection strings for the same model (depending on the location of the user will depend on which database the user gets directed to).
The next issue we are having is that we can't the return types of stored procedures to be auto-generate. I have tried to retrieve the column information but it is never able to retrieve the metadata. I have seen a few suggestions of modifying the stored procedures then getting the column information and reverting the stored procedures but this is something we would like to avoid. Also the suggestions don't seem to work on oracle databases (but that could be me, I don't have much experience with databases).
The final issue (this is a minor issue) is that I cannot figure out how to get the generate code to omit underscores from the classes/methods generated. This isn't a huge issue it is purely to make it easier migrating the code we have.
The scenario that created this question:
We have a package that is a dependency of another package, sometimes making changes to the "parent" package causes the dependent package to become invalid, but sometimes it doesn't.
It has caught us by surprise before.
It would be very useful to simply understand what causes invalidation so I could predict/plan for it.
Changing anything object that a package relies upon (e.g. tables, views, triggers, other packages) will automatically mark the package as invalid. As tuinstoel notes above, Oracle is smart enough to recompile the package when it is first used.
If you are concerned about this, every time you make schema changes (e.g. tables, views, triggers, procedures), run a DBMS_UTILITY.compile_schema (or have your DBA do it). This will force compile all the packages and let you know where, or if, there are errors before you find them the hard way.
Or you can query the following table to see what dependencies you have
select *
from dba_dependencies
where name = 'YOUR_PACKAGE'
and referenced_owner = 'ANYUSER' --- Comment this out if you are looking for yourself
and owner = USER --- Or can be set to any user
This will show all dependencies. For your objects query user_dependencies.
I agree with Thomas Jones-Low however there are a couple more issues to do with long sessions and recompilation.
If you reference a package in a session and that package (or a dependant package) gets recompiled during the same session then you'll get oracle error "ORA-06508: PL/SQL: could not find program unit being called"
Once you've referenced the package in a session you generally can't change the package without invalidating it for that session. This is a particular problem for development environments where packages change frequently but also a problem for production environments where you want to do a small patch without taking the whole environment down. Note that this error will occur even when there are no errors in the changed packages.
BTW, If I'm completely wrong about the situation... apologies in advance
Caught by surprise?
Not sure what the implications of that are...
Did something break in production?
What EXACTLY happened?
The reason I ask is because understanding every possible change's ramifications is much harder than dealing with the outcome. Why the invalidation become an issue? My guess is because you got an "Existing state of Package has been discarded" error in your application. Is that the REAL issue?
Again I suspect that it is and if so, let's just deal with that instead of the list of changes which as I put in a comment is version specific. (11g tracks dependency down to the column of a table instead of the table as a whole for example).
This may not seem like an important error to you if you're not using package state. If you were this would be an important error and you wouldn't have been surprised, so I'm guessing you're not.
Since you are not this error is ok to ignore. Since you can safely ignore it, you can code your client app to ignore this error and retry your call, because, as others have pointed out Oracle will recompile your package for you. This is a worthwhile exercise. Because rather than knowing every possible thing you need to worry about when you make a change, and then in the emergency fix you forget one of those, your app will just handle it and move on, without worry.
In addition to Thomas Jones-Low's answer, if you only modify the package BODY, a dependent object might not be marked as invalid.
However, as soon as you modify the package specification, that is bound to happen.
If try to execute an invalid Oracle package, Oracle will try to compile it. Only when it remains invalid after compiling Oracle will throw an exception.
I'm running into a very annoying issue. One of our SPROC is building up a dynamic bit of SQL which is then executed with sp_executesql (please let's not go into the issues with building up SQL strings for execution).
Using Visual Studio 2010 Database Project (aka. DataDude) to to schema comparisons and deployments and I'm getting the error below for the SPROC:
TSD00563 This deployment may encounter errors during execution because [dbo].[MYSPROC] depends on [sys].[sp_executesql] and [sys].[sp_executesql] does not exist in the target database
Does anyone know how I can get around this?
I have a reference to the master database schema file, but it makes no difference. Also, it's not referencing master, but sys instead.
Many thanks,
Jaans
"The issue you mentioned is a known issue, we had fixed this for RTM. And when you add a db reference to master .dbschema file, you need to make sure the database name part is choosed as literal and named "master""
http://social.msdn.microsoft.com/Forums/en-US/vstsdb/thread/68b0ce97-5275-42af-b213-bd456ce882d7
Use a . prefix before the [sys].[sp_executesql]
Here's an example
EXEC .sys.sp_executesql 'SELECT * FROM Table'
Strange indeed!
The scenario that created this question:
We have a package that is a dependency of another package, sometimes making changes to the "parent" package causes the dependent package to become invalid, but sometimes it doesn't.
It has caught us by surprise before.
It would be very useful to simply understand what causes invalidation so I could predict/plan for it.
Changing anything object that a package relies upon (e.g. tables, views, triggers, other packages) will automatically mark the package as invalid. As tuinstoel notes above, Oracle is smart enough to recompile the package when it is first used.
If you are concerned about this, every time you make schema changes (e.g. tables, views, triggers, procedures), run a DBMS_UTILITY.compile_schema (or have your DBA do it). This will force compile all the packages and let you know where, or if, there are errors before you find them the hard way.
Or you can query the following table to see what dependencies you have
select *
from dba_dependencies
where name = 'YOUR_PACKAGE'
and referenced_owner = 'ANYUSER' --- Comment this out if you are looking for yourself
and owner = USER --- Or can be set to any user
This will show all dependencies. For your objects query user_dependencies.
I agree with Thomas Jones-Low however there are a couple more issues to do with long sessions and recompilation.
If you reference a package in a session and that package (or a dependant package) gets recompiled during the same session then you'll get oracle error "ORA-06508: PL/SQL: could not find program unit being called"
Once you've referenced the package in a session you generally can't change the package without invalidating it for that session. This is a particular problem for development environments where packages change frequently but also a problem for production environments where you want to do a small patch without taking the whole environment down. Note that this error will occur even when there are no errors in the changed packages.
BTW, If I'm completely wrong about the situation... apologies in advance
Caught by surprise?
Not sure what the implications of that are...
Did something break in production?
What EXACTLY happened?
The reason I ask is because understanding every possible change's ramifications is much harder than dealing with the outcome. Why the invalidation become an issue? My guess is because you got an "Existing state of Package has been discarded" error in your application. Is that the REAL issue?
Again I suspect that it is and if so, let's just deal with that instead of the list of changes which as I put in a comment is version specific. (11g tracks dependency down to the column of a table instead of the table as a whole for example).
This may not seem like an important error to you if you're not using package state. If you were this would be an important error and you wouldn't have been surprised, so I'm guessing you're not.
Since you are not this error is ok to ignore. Since you can safely ignore it, you can code your client app to ignore this error and retry your call, because, as others have pointed out Oracle will recompile your package for you. This is a worthwhile exercise. Because rather than knowing every possible thing you need to worry about when you make a change, and then in the emergency fix you forget one of those, your app will just handle it and move on, without worry.
In addition to Thomas Jones-Low's answer, if you only modify the package BODY, a dependent object might not be marked as invalid.
However, as soon as you modify the package specification, that is bound to happen.
If try to execute an invalid Oracle package, Oracle will try to compile it. Only when it remains invalid after compiling Oracle will throw an exception.