Nice try

Tired of looking this up... so I'm posting it. I don't use the unix nice command very often, but when I do, the man page seems a little confusing. Here's the format I typically use the command:

nice -n +19

That runs the command at the lowest possible priority, helpful if you're going to do some big file op and don't want to cause anyone else any grief.

What service has oci.dll open?

Attempting to use deployment procedure's to install patch bundles on windows hosts, sometimes you run into issues with services keeping dll's (especially oci.dll) open.

Here's a trick to determining what service is keeping a specific dll open.

From a command prompt:

tasklist /m > tasks.txt 

notepad tasks.txt 

The look for the specified dll in tasks.txt and find the process. From there it should be somewhat obvious which service to shut down in order to get the patch to continue.

ORA-01406: fetched column value was truncated

I just got a dump file of our data from a vendor that is hosting an application for us and I was making it available to my developers and since we will be getting files on a somewhat frequent basis, initially I created an external table to read the data.

I had to get over the first hurdle of version incompatibility of the datapump file, which wasn't too bad, but after I cleared up those issues (lots of references on google, this chart helped the most) I received the following error in Toad:

ORA-01406: fetched column value was truncated

with further details

fetched column value was truncated

Cause: In a host language program, a FETCH operation was forced to truncate a
character string. The program buffer area for this column was not large enough to
contain the entire string. The cursor return code from the fetch was +3. 

Action: Increase the column buffer area to hold the largest column value or perform
other appropriate processing.

Google wasn't as helpful with this (hence the post here), but essentially this is a client side setting that needs to be adjusted. In version 10.6.1.3 of Toad there is one setting that needs to be changed. Search for "OCI Array Buffer size" or find it under "Oracle - General". You need to change it to be large enough to fetch the largest column in the query. In my case I had a column of size 4000, so setting this to 4000 returned results.

Fun with Logon Triggers

Sometimes a process happens too fast to be traced effectively, but it's happening slowly enough to make your users angry.

Here's an example of a logon trigger setup to make a trace happen, we're using it to diagnose an issue with slow response from an ODBC connection, using user account ADMIN_JOSH:

DROP TRIGGER SYSTEM.JOSH_LOGINTRIGGER;
 
CREATE OR REPLACE TRIGGER SYSTEM.Josh_LoginTrigger AFTER LOGON ON ADMIN_JOSH.SCHEMA
BEGIN
   execute immediate 'ALTER SESSION SET tracefile_identifier = MYTRACEFILE';
   execute immediate 'alter session set sql_trace=true';
END;
/

Note if you get the following error, the owner of the trigger needs the alter session priv (in this case system).

ORA-00604: error occurred at recursive SQL level 1
ORA-01031: insufficient privileges
ORA-06512: at line 2

It's the env, stupid

While performing the following...

$ORACLE_HOME/forms/lib32/make -f ins_forms.mk install

Got the following error:

ld: fatal: library -ljvm: not found
ld: fatal: File processing errors. No output written to frmbld
make: *** [frmbld] Error 1

Apparently no one else has ever reported this problem before...

Turns out the user's env didn't include LD_LIBRARY_PATH. Fixed that, and problem was solved.

It pays to read the documentation

Had an issue where I couldn't get forms builder to work.

Here's the error code:

# frmbld
FRM-91111: Internal Error: window system startup failure.
FRM-10039: Unable to start up the Form Builder.

It should work right out of the box, looks like the build config had changed much, here's the env file used:

ORACLE_HOME=/u01/app/oracle/product/ias10gds
export ORACLE_HOME
LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/jdk/jre/lib/sparc:$ORACLE_HOME/jdk/jre/lib/sparc/native_threads
export LD_LIBRARY_PATH
PATH=$ORACLE_HOME/bin:$ORACLE_HOME/opmn/bin:/usr/local/bin:/usr/ccs/bin:/bin:/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/usr/ucb:/usr/ccs/bin:/usr/sbin:/usr/X/bin:$ORACLE_HOME/OPatch
export PATH
FORMS_PATH=/u01/app/sct/baninbr2/QUAL/forms/fmb
export FORMS_PATH

Eventually found this documentation post about how to solve the problem. Basically since the last time we used forms builder on this server, the other Oracle homes required a change to NLS_LANG with a UTF8 characterset.

Simply added the following to the above forms builder env file fixed the issue with forms builder:

export NLS_LANG=

Problem solved.

Before you set global_names=true

For all the years that I've been working with Oracle I have not had to deal with the oracle streams capture/apply processes. Other DBA's on my team have had to work with it, but I didn't get the hands on experience. That is until past weekend when I had installed a streams backed process for our identity management product for creation of downstream accounts.

Part of the installation process was to set global_names=true, which as I have now found out is the recommendation from oracle. From what little I know about it, it is for additional security as well as preventing bad things from happening during clones (or so I've read).

It turns out that one of the results from enabling global_names is that you end up getting "ORA-02085: database link FOO.DB.COM connects to BAR.DB.COM" when the database link name does not match the target.

I tried "fooling" it with everything I could think of that didn't involve rewriting any of the code that calls the database link, but nothing in fact worked. The name itself has to be changed to match the target database name (which is clearly stated in oracle documentation...I hoped it was a lie).

This was new to me.

I currently have set global_names=false until I can figure out how much code has to be reworked reflecting all the database link name changes.

So the one thing I should have checked into before setting global_names to true was which database links were going to fail after the switch. And had I done that before, I would have realized the answer would be... all of them. At least now I can push for a new standard for everyone to follow when they create database links.