The error I'm getting is "no more data to read from socket" on this line
COALESCE( NonRewrite.SALES_LOG_DATE, SYSDATE) "SoldDate"
Oddly, I can just do NonRewrite.SALES_LOG_DATE and there are no null values anyway. If I do SYSDATE alone it gives me the same error.
If I replace SYSDATE with TO_DATE('18-MAR-2016')), I do not receive an error.
"no more data to read from socket" is a generic error that doesn't really tell you the problem. That error means a database process crashed so hard it didn't even raise a proper exception and the connection died unexpectedly.
When that happens Oracle stores an error message in the alert log, which you can find in the path found from this query: select value from v$parameter where name = 'background_dump_dest';. Look for a file named alert*.log.
In that file there will probably be an ORA-600 or ORA-7445 error around the same time as the exception. The error usually has several parameters, for example ORA-00600: internal error code, arguments: [ktfbtgex-7], [1015817], [1024], [1015816], [], [], [], [].
The first parameter is usually the most important one. If you're lucky you can Google it and find an answer. But usually you'll need to login to support.oracle.com and search for that error. There's a special page for that, search for the "ora-600 tool". That will bring up a page to search for the first parameter of the error message.
Hopefully that tool will bring up specific documents that explain the problem. There may be a patch, or a workaround, or possibly no information at all. It's usually easiest to workaround the problem by avoiding some very specific combination of features, possibly by slightly re-writing the query.
Post the error message, the exact Oracle version, and the entire query and someone may be able to help. If the query is large you'll want to shrink it as much as possible. Shrinking the query and making a reproducible test case may take a few hours but is necessary to truly understand the problem. People who don't spend the time doing that usually end up avoiding important features and give bad advice to other developers like "avoid SYSDATE!".
These types of errors may take a long time to fix.
Related
I am doing reporting in OTBI (Oracle Cloud). Can any one help me to customize "General Ledger Trial Balance Report". I am getting error as
ORA-20101: ORA-06512: at "FUSION.GL_GLGENLED_XMLP_PKG"
while editing the data model for the standard Report. Any one have any idea.
ORA-20101 isn't Oracle built-in error; codes from -20000 to -20999 are custom-reserved codes, so I suppose that it was used by developer who raised it in package/procedure you named. If you have access to it, search for "20101" and see why it happened.
ORA-06512, on the other hand, means that you hit an unhandled exception at line #4. That's good for troubleshooting (i.e. looking at that piece of code and find the culprit at line #4). But, if you don't/can't review that procedure, huh, you're in trouble. Basically, there are 3 ways out:
fix the error yourself, if you can
write an exception handler which will handle that situation (if you can)
ask your DBA for help
I'm not sure whether you can do anything of above as it looks like Oracle-written procedure, so ...
Finally, your last resort is to contact Oracle Support and ask for assistance.
My oracle 12c (12.1.0.1) database stop working last night (actually It worked but very very slow) , and started throwing the following exception:
java.sql.SQLException: ORA-00600: internal error code, arguments::
[KGL-heap-size-exceeded], [0x07B292C58], [0], [524314616], [], [], [],
[], [], [], [], []
Have not idea what is causing this problem, and I can't find any useful information. Does anyone knows about this "KGL heap size exceeded"? Thanks
ORA-00600 errors are bugs in Oracle's software and should first be investigated on support.oracle.com. Many of the support documents are not public and cannot be found on any other search engine.
When you get to that site, search for "ora-600 tool", which will bring you to a special page. That page will ask you for the first argument. Enter KGL-heap-size-exceeded, hit "Look-up Error", and it will show a single document with more information - "ORA-600 [KGL-heap-size-exceeded] (Doc ID 1662971.1)".
That document includes links to 5 different bugs. I'm not sure which is the relevant bug, it depends on your version and exactly how the bug happens. And there are many bugs that aren't even published on My Oracle Support.
After you've looked on the website, and tried either solving or avoiding the problem, then you might want to create a ticket. But do not immediately create a ticket for every ORA-00600 error or you will waste a tremendous amount of time.
There is usually a trace file associated with this error which gives a details of the error. in order to resolve you need to set this parameter
alter system set "_kgl_large_heap_warning_threshold"=88608 scope=spfile sid='*';
In the example above I set the value to 8MB.
I have a 400 line sql query which is throwing exception withing 30 seconds
ORA-03113: end-of-file on communication channel
Below are things to note:
I have set the timeout as 10 mins
There is one last condition when removed resolves this error.
This error came only recently when I analyzed indexes.
The troubling condition is like this:
AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%')
So my assumption is that the query is getting terminated from the server side apparently because its identified as a resource hog.
Is my assumption appropriate ? How should I go about to fix this problem ?
EDIT: I tried to get the explain plan of faulty query but the explain plan query also gives me an ORA-03113 error. I understand that my query is not very performant but why should that be a reason for ORA-03113 error. I am trying to run the query from toad and there are no alert log or trace generated, my db version is
Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production
One possible cause of this error is a thread crash on the server side. Check whether the Oracle server has generated any trace files, or logged any errors in its alert log.
You say that removing one condition from the query causes the problem to go away. How long does the query take to run without that condition? Have you checked the execution plans for both versions of the query to see if adding that condition is causing some inefficient plan to be chosen?
I've had similar connection dropping issues with certain variations on a query. In my case connections dropped when using rownum under certain circumstances. It turned out to be a bug that had a workaround by adjusting a certain Oracle Database configuration setting. We went with a workaround until a patch could be installed. I wish I could remember more specifics or find an old email on this but I don't know that the specifics would help address your issue. I'm posting this just to say that you've probably encountered a bug and if you have access to Oracle's support site (support.oracle.com) you'll likely find that others have reported it.
Edit:
I had a quick look at Oracle support. There are more than 1000 bugs related to ORA-03113 but I found one that may apply:
Bug 5015257: QUERY FAILS WITH ORA-3113 AND COREDUMP WHEN QUERY_REWRITE_ENABLED='TRUE'
To summarize:
Identified in 9.2.0.6.0 and fixed in 10.2.0.1
Running a particular query
(not identified) causes ORA-03113
Running explain on query does the
same
There is a core file in
$ORACLE_HOME/dbs
Workaround is to set
QUERY_REWRITE_ENABLED to false: alter
system set query_rewrite_enabled =
FALSE;
Another possibility:
Bug 3659827: ORA-3113 FROM LONG RUNNING QUERY
9.2.0.5.0 through 10.2.0.0
Problem: Customer has long running query that consistently produces ORA-3113 errros.
On customers system they receive core.log files but do not receive any errors
in the alert.log. On test system I used I receivded ORA-7445 errors.
Workaround: set "_complex_view_merging"=false at session level or instance level.
You can safely remove the "UPPER" on both parts if you are using the like with numbers (that are not case sensitive), this can reduce the query time to check the like sentence
AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%')
Is equals to:
AND someMultiJoin.someColumn LIKE '%90936%'
Numbers are not affected by UPPER (and % is independent of character casing).
From the information so far it looks like an back-end crash, as Dave Costa suggested some time ago. Were you able to check the server logs?
Can you get the plan with set autotrace traceonly explain? Does it happen from SQL*Plus locally, or only with a remote connection? Certainly sounds like an ORA-600 on the back-end could be the culprit, particularly if it's at parse time. The successful run taking longer than the failing one seems to rule out a network problem. I suspect it's failing quite quickly but the client is taking up to 30 seconds to give up on the dead connection, or the server is taking that long to write trace and core files.
Which probably leaves you the option of patching (if you can find a relevant fix for the specific ORA-600 on Metalink) or upgrading the DB; or rewriting the query to avoid it. You may get some ideas for how to do that from Metalink if it's a known bug. If you're lucky it might be as simple as a hint, if the extra condition is having an unexpected impact on the plan. Is someMultiJoin.someColumn part of an index that's used in the successful version? It's possible the UPPER is confusing it and you could persuade it back on to the successful plan by hinting it to use the index anyway, but that's obviously rather speculative.
It means you have been disconnected. This not likely to be due to being a resource hog.
I have seen where the connection to the DB is running over a NAT and because there is no traffic it closes the tunnel and thus drops the connection. Generally if you use connection pooling you won't get this.
As #Daniel said, the network connection to the server is being broken. You might take a look at End-of-file on communication channel to see if it offers any useful suggestions.
Share and enjoy.
This is often a bug in the Cost Based Optimizer with complex queries.
What you can try to do is to change the execution plan. E.g. use WITH to pull some subquerys out. Or use the SELECT /*+ RULE */ hint to prevent Oracle from using the CBO. Also dropping the statistics helps, because Oracle then uses another execution plan.
If you can update the database, make a test installation of 9.2.0.8 and see if the error is gone there.
Sometimes it helps to make a dump of the schema, drop everything in it and import the dump again.
I was having the same error, in my case what was causing it was the length of the query.
By reducing said length, I had no more problems.
I was wondering what the general consensus on error messages was. How detailed should they be?
I've worked on projects where there was a different error message for entering a number that was too big, too small, had a decimal, was a string, etc. That was quite nice for the user as they knew exactly where things went wrong, but the error handling code started to rival the actual business logic in size, and started to develop some of its own bugs.
On the other side I've worked on a project where you'd get very generic errors such as
COMPILE FAILED REASON 3
Which needless to say was almost entirely useless as reason 3 turned out to mean a link error.
So where is the middle ground? How do I know if I've added descriptive enough error messages? How do I know if the user will be able to understand where they've gone wrong?
There are two possible target audiences for an error message, the user, and the developer.
One should generally have the message target the user.
o what is the cause of the problem.
o why the program can't work around the problem
o what the user can do to work around the problem.
o how to report the problem.
If the problem is to be reported, the report should include as much program context information as possible.
o module name
o function name
o line number
o variables of interest in the general area of the problem
o maybe even a core dump.
Target the correct audience.
You should communicate what happened, and what the user's options are, in as few words as possible. The longer the error message is, the less likely the user is to read it. By the same token, short error messages are cryptic and useless. There's a sweet spot in terms of length, and it's different for every situation.
Too short:
Invalid input.
Too long:
Please enter a correctly formatted IP address, such as 192.168.0.1. An IP address is a number used to identify your computer on a network.
Just right:
Please enter a valid IP address.
As far as code bloat is concerned, if a little extra code will prevent a user from calling support or getting frustraited, then it's a good investment.
There are two types of error messages: Those that will be seen by the user and those that'll be seen by the programmer.
"How do I know if the user will be able to understand where they've gone wrong?"
I'm assuming that those messages are only going to be seen by the user, and not a very technical one, and COMPILE FAILED REASON 3 is not a typical end-user error message. It's something that the programmer will see(the user doesn't usually compile things).
So, if it's the user that'll see it:
Provide a short "This is an error message"("Ops! Something went wrong!", etc.)
Provide a small generic description of the error ("The site you're trying to connect to seems to be unavailable"/"You don't seem to have enough permissions to perform the XYZ task"/etc.)
Add a "Details>>" button, in case your user happens to understand computers well, including detailed information(exception stack trace, error code, etc.)
Finally, provide some simple and understandable commands for the user ("Try again", "Cancel", etc.)
The real question about error messages is if they should even be displayed. A lot of error messages are presented to a user but there is NO WAY for them to correct them.
As long as there is a way to correct the error then give enough information to the user that will allow them to correct it on their own. If they are not able to correct it on their own is there any reason to tell them the technical reason for the crash? No just log it to a file for troubleshooting later.
As detailed as they need to be ;)
I know it sounds like a smart ass answer but so much of this depends on your target audience and the type of error. For errors caused by invalid user entry, you could show them what constitutes a valid entry. For errors that the user can't control, a generic "we're working on it" type message might do.
I agree with Jon B's comments regarding length as well.
Error messages should be detailed, but clear. This can be achieved by combining error messages from multiple levels:
Failed to save the image
Permission denied: /foo.jpg
Here we have two levels. There can be more. First we tell the big picture and then we tell the details. The order is such that first we have the part understood by most and then the part less people understand, but both can still be visible.
Additionally there could be a fix suggestion.
I would err on the side of more detail, but I think you answered your own question. To avoid the bloat in code then provide useful information in the code/error message but you can give more details in the documentation perhaps or with help files or FAQ.
having too little information is worse in my opinion.
If you are using a language with rich introspection or other capabilities, a log witht he line that failed a check would be useful. The user can then forward to tech support or otherwise get detailed information and this is not additional code bloat, but using your own code to provide information.
We are changing some of the text for our old, badly written error messages. What are some resources for best practices on writing good error messages (specifically for Windows XP/Vista).
In terms of wording your error messages, I recommend referring to the following style guides for Windows applications:
Windows user experience guidelines, and specifically the section on error messages here.
Microsoft Manual of Style
The ultimate best practice is to prevent the user from causing errors in the first place.
Don't tell users anything they don't care about; error code 5064 doesn't mean a thing to anyone. Don't tell them they did something wrong; disallow it in the first place. Don't blame them, especially not for mistakes your software made. Above all, when there is a problem, tell them how to fix it so they can move on and get some work done.
A good error message should:
Be unobtrusive (no blue-screen or yellow-screen of death)
Give the user direction to correct the problem (on their own if possible, or who to contact for help)
Hide useless, esoteric programmer nonsense ( don't say, "a null reference exception occurred on line 45")
Be descriptive without being verbose. Just enough information to tell the user what they need to know and nothing more.
One thing I've started to do is to generate a unique number that I display in the error message and write to the log file so I can find the error in the log when the user sends me a screenshot or calls and says, "I got an error. It says my reference number is 0988-7634"
For security reasons, don't provide internal system information that the user does not need.
Trivial example: when failing to login, don't tell the user if the username is wrong or the password is wrong; this will only help the attacker to brute force the system. Instead, just say "Username/Password combination is invalid" or something like that.
Always include suggestions to Remedy the error.
Try to figure out a way to write your software so it corrects the problem for them.
For any user input (strings, filenames, values, etc), always display the erroneous value with delimiters around it (quotes, brackets, etc). e.g.
The filename you entered could not be found: "somefile.txt"
This helps to show any whitespace/carriage returns that may have sneaked in and greatly reduces troubleshooting and frustration.
Avoid identical error messages coming from different places; parametrize with file:line if possible, or use other context that lets you, the developer, uniquely identify where the error occurred.
Design the mechanism to allow easy localization, especially if it is a commercial product.
If the error messages are user-visible, make them complete, meaningful sentences that don't assume intimate knowledge of the code; remember, you're always too close to the problem -- the user is not. If possible, give the user guidance on how to proceed, who to contact, etc.
Every error should have a message if possible; if not, then try and make sure that all error-unwind paths eventually reach an error message that sheds light on what happened.
I'm sure there will be other good answers here...
Shorter messages may actually be read.
The longer your error message, the less the user will read. That being said, try to refactor the code so you can eliminate exceptions if there is an obvious response. Try to only have exceptions that happen based on things beyond your user or your code's control.
The best exception message is the one you never have to display.
Error handling is always better than error reporting, but since you are retrofitting the error messages and not necessarily the code here's a couple of suggestions:
Users want solutions, not problems. Help them know what to do after an error, even if the message is as simple as "Please close the current window and retry your action."
I am also a big fan of centralized logging of errors. Make sure the log is both human and computer scanable. Users don't always let you know what problems they are having, especially if they can be 'worked around', so the log can help you know what things need fixed.
If you can control the error dialog easily, having a dialog which shows a nice, readable message with a 'details' button to show the error number, trace, etc. can be a big help for real-time problem solving as well.
Support for multilanguage applies for all kinds of messages, but tends to be forgotten in the case of error messages.
I would second not telling the user useless esoteric information like numeric error codes. I would follow that up however by saying to definitely log that information for troubleshooting by more technically savvy people.