If you try to insert or update across a database link some values called by a user defined function: insert into mytable@remote (mycol) values ( myfunction (’01-JAN-2009′) ) ; That will fail with either: ORA-02019: connection description for remote database not found or ORA-02069: global_names parameter must be set to TRUE for this operation There […]Read More Bug (ora-2019 or ora-2069) with User Defined Functions Insert/Update over Database Links
Thanks to Chris Carr for pointing out this: If you are upgrading or patching to 10.2.0.3 and the word size is different to the word size when the database was created the upgrade will fail with an ora-600. This applies even if the wordsize has been changed in an interim upgrade i.e. 8.1.7 32bit upgraded […]Read More 10.2.0.3 patch fails if database word size had ever been changed in the past
This would seem to be pretty authoritative: “And on the seventh day God ended his work which He had made; and he rested on the seventh day from all his work which He had made. And God blessed the seventh day, and sanctified it; because that in it he had rested from all his work […]Read More And on the seventh day, God fiddled with His NLS settings
So I had: ORA-08103: object no longer exists being reported on SQL affecting one application table. But that table existed ok in dba_tables, could be described ok, and selects restricted to its indexed columns returned data ok. Suspicion was some sort of data block corruption. Rman backup logs had not reported any corrpution, but dbverify […]Read More Data block corruption cleared with alter system flush buffer_cache
Wouldn’t it be nice if sql code produced the same result, regardless of whether it is inside a stored procedure or is a standalone plsql block? But that’s not what happens when the all_ views are used. Run this code to see the anomaly for yourself: set serverout on declare var1 number ; begin select […]Read More Bug? with wrong results from all_objects in stored plsql procedures
Using the below memory listing script, I found two databases with large PGAs. That was strange since pga_aggregate_target was unset, sort_area_size was just 64k, and there were very few sessions. Checking PGA at session level showed the QMN sessions had high memory usage (over 200mb each). Which pointed to bug 2227360 “QMN process leaking memory” […]Read More Pre 9202/9014: Advanced queuing runs away with server memory.