Oracle blog – NIOUG

Errors are not really a welcome stuff . Yesterday, I was importing a dump file (from 8.1.7.4) into 10.2.0.3 and hit

IMP-00020: long column too large for column buffer size (number).

After doing some googling and searching on metalink came to know (not sure though) that it was some bug in 8.1.7.4. And the solution was to try with different values of buffer parameter in import (which actually didn’t help) . Thats what oerr also has to say:

*Cause: The column buffer is too small. This usually occurs when importing LONG data.
*Action: Increase the insert buffer size 10,000 bytes at a time (for example). Use this step-by-step approach because a buffer size that is too large may cause a similar problem.

And also probably the issue was that the export was run with compress=N. So the guys again ran the export of the table with compress=Y (which is the default). Hopes got some oxygen and we again ran the import. That IMP-00020 was gone and a new baby struck:

IMP-00058:Oracle Error 1438 encountered.
ORA-01438:Value Larger Than Specified precision allow for this Column

Again started the googling and metalink’ing session and found that it was some bug . Import itself creating the table and then uttering ORA-01438. Complete non-sense. Isn’t it ? Just hitting and trying what we did was pre-created the table with all the NUMBER columns having their data types defined simply as NUMBER without any precision and wow it completed without any errors. Now its stupid seriously.

So then we did some research on the data in the table and found that there was one row which was causing the whole shit. There were two columns defined as NUMBER(12) but the values in them were of length 30 and 60. So what it was ? Probably a data corruption or what ? Otherwise how the table definition would have allowed such crap to enter the table. Couldn’t ascertain the exact reason but happy ending, it was

Today in my program, we hit with an almost uncertain error. We were trying to create listener using EM console but it was throwing us an error that the location is not the right one when the location was perfectly alright. I am not sure what actually is the error but despite the best effort, I couldn’t get any clue.

Now, this was not solved but in the meanwhile some one asked me that what is the use of NetProperties file which is available in $ORACLE_HOME/network/tools. This file is used by the network related tools, for example Net manager, Net Configuration Assistant etc. Despite searching alot, I couldn’t find anything about it either. Grrr!

Well , both the things didn’t lead to no where but some how in the search, I stumbled upon a workaround that we need to do these changes in the Netproperties file to make EM work,

1)Go to $oracle_home/nework/tools
2)In the file Netproperties, comment the line INSTALLEDCOMPONENTS=ORACLENET

And it did work. Now the million dollar question is what does this setting means and why did comment it? And the zillion dollar question( since the starting) remains yet a mystery that what does Netproperties file control?

Search continues….

Aman….

Its not at all a good situation when anyone has to go face to face with ORA-00600. Well its not a nice error message to see and that too when you had least expected it. So what happens when this error comes? Actually there is no one reason for it. This error is an internal error raised by some issue occuring within the oracle’s code. There can be many reasons for this error to come and certainly I shall not cover them all here in this post itself. This post is about a specific ora-600 code that I have mentioned in the title and how did I overcome that. If you are interested than carry on reading.

Few days back we were in our lab and our machines were not in the network. We didn’t need the network too so we didn’t bother. In one of the discussions, there was a requirement that asked for network to be up. Those were Linux machines and students didn’t know how to enable network over there. Well I know a little about Linux so I did make it enable and also enabled the use of DHCP . Nothing seems to be wrong, network was up, internet also came up and Oracle was working fine. I would mention here that our /etc/hosts file was empty as the host information was not required and was picked up by DHCP. After one scenario, we needed to bounce the database.

After instance startup, we were greeted with ora-00600[keltnfy-ldmInit],[46],[1]. Well this ora-600 comes, its always suggested to contact support to find the cause and remedy for it. The problem was I couldn’t call support for me and the other solution was to re-install all the machines. Well I did read some where that all the codes of ora-00600 doesn’t mean that oracle needs to be contacted to rectify it. So I searched a bit and found that this error code that came to us is Oracle’s way of saying that it couldn’t find the information of the host on which it was sitting. Its certainly true as we had enabled DHCP and Oracle is not at all happy with DHCP enabled systems.

So what happened was that Oracle was looking for the host information from the /etc/hosts file but it was empty. Now for oracle to start, it needs a host name. As the file was empty , it couldn’t find anything about it from there. So it stopped the mounting of the database. So the solution was that we edited the /etc/hosts file and entered the host information with host name as “local host” and the IP address that we were getting at that time. As the machines wouldn’t be rebooted so it was safe to enter that value. Tried starting oracle and voila! We were back in the business!

Our database was 10201 on RHEL. This error is also removed from upgrading db to 10202 and further. So if you are on 10201 and are facing this error, you need to have the patch applied to it and upgrade to 10202.

Though I did remove this error with a little search but still the fact doesn’t change that when you hit ora-600, its high time to contact Oracle Support Services as you have hit some thing really serious.