1. symptom description:
Yesterday, colleagues at the site reported that the stored procedure sent to him over the weekend caused sqlplus to fail to respond for a long time during deployment, and the stored procedure could not be deployed at the site.
2. Problem Analysis:
A. Whether the version is correct.
Because the database version used during development is 10.2 and the database version running on site is 10.1, it is first suspected that this problem is caused by the version, and then the possibility is ruled out, because there is no problem with the initial deployment of the stored procedure of the previous project.
B. Is there a problem with writing a new program?
My colleague asked me whether the problem was caused by this process. This proposal was rejected, and a program problem is unlikely to cause this phenomenon.
C. Suspicious database locks.
Restart the database and try again. the problem persists.
After the above analysis, and try to use other tools for deployment, the results are the same.
3. Further analysis:
In desperation, we had to remotely dial and view the database logs. No exception was found, and no problem was found when other users logged on to the database. This problem does not occur when you re-find the machine and deploy it locally according to the installation documentation. Ask colleagues in the family to redeploy according to the document. The result shows that dblink is not correctly established during on-site deployment. After dblink is corrected, the stored procedure is redeployed.
4. Conclusion:
A large number of synonyms are used in the new storage process, and these synonyms are created through dblink, resulting in too many errors during the deployment and compilation of the storage process, resulting in sqlplus "false ".