Oracle ias/db problem.

[Steven E. Protter]

Update: We have vastly increased shared memory resources, doubled nproc and other parameters affected by this.

Moved the new kernel into production. No effect.

Really, really, really frustrating. Please keep trying folks.

Does anyone want to see a database trace?

Attached.

[R. Allan Hicks]

You might try turning the tracing on for the 12333 error. Use netmgr to set to admin or even support trace levels.

One of the more annoying features that I have found with the 9i networking stuff is the service name is now case sensative.

Also note in Tom Kyte's 8i book (Expert one on one Oracle pg 3590, he warns that doing an exp from a db with one character set and an imp into a db with a different one can cause unexpected character conversions. Since you moved to a non UTF-8 makes me wonder.

-hmmmmmmmmm

[Brian Crabtree]

Have you thought about moving from 8.1.7.4.0 64bit to 32bit, or upgrading to 9.2.0.3.0 64bit? Possibly changing the character set if you are not locked into Unicode might resolve the problem as well.

Brian

[Steven E. Protter]

Brian,

can you elaborate. I'm not lead on this issue, and I don't understand what you are recommending.

SEP

[Brian Crabtree]

The major difference between 64bit and 32bit is the amount of allowable memory. Unless you need over 2g in SGA, or the application requires the 64bit wordsize to be used, you can probably move back to 32bit without a major issue (new binary installation, rebuild the controlfile with the new Oracle home, and run the utlirp.sql script to recompile the objects). This would probably be the easiest option to see if that resolves the problem.

The second option is to change the character set being used. UTF8 is a unicode character set, which encompasses most of the available characters that can be put on the database. You would need to define which characters are going to be put into the database (ie: English only requires US7ASCII, Western European (all character sets starting with WE) hold most of the special characters from German, Spanish, French, etc. The following is a metalink document of all of the character sets with what they carry, as well as bit sizes, etc.

http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=226492.1

To do this, you would want to export your database with current character set, rebuild the database with the new character set, and import with NLS_LANG set to the new character set. This should move your data into the new character set.

The last option would be to move the database off of 8i entirely, and move to 9i. I would recommend 9.2.0.3.0. This version has appeared to be stable on the systems that we have placed it on. There is a learning curve associated with it if you are used to using 'svrmgrl' or the 'internal' connection, however it is not incredibly difficult to get used to.

You can also run specific traces from Oracle to define the problem, however in my experiance in trying to diagnose the problem, there wasn't a single cause that generated the error, and it almost always looked like it was a fault of the application.

Thanks,

Brian

[Brian Crabtree]

Actually, here is a better link (dont assign points, this is just an addition to above). This one shows the languages associated with each character set.

http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_id=62421.1&p_database_id=NOT

Brian

[Steven E. Protter]

Update: We have successfully run an application est in X/Windows motif and the results are quite interesting.

In motif using oracle runtime, which is essentially client/server mode on two servers, the application gave the exact same troublesome behavior.

This eliminates jinitiator as a cause because you don't use jinitiator in that mode.

It seems to eliminate forms as an issue because the problem comes up in this mode. We are next going to take the form on the bad server and connect to a good database running on one of our 11.00 servers. If the problem does not occur its definitely a datbase problem on the bad server. If the problem recurs, then we know for sure its a forms problem on the bad servers.

SEP

[Steven E. Protter]

Testing finally indicated the problem was with forms, not the database.

We cross tested a good forms instance against the potential trouble database and a the potential bad forms install against a known good database.

The results pointed to forms, one of Oracle's shared libraries didn't get created properly. When Oracle sent us theirs the problem stopped happening.

Now Oracle's scratching their head trying to figure out why their library got corrupted. When Oracle finally got around to actually READING the tusc output and the database trace it pointed straight to the Oracle provided libraries.

I don't think anything else is going to come out of this thread other than an Oracle bug fix or me posting the solution. I'll get back to you.

SEP