Posted by Alex Gorbachev on May 26, 2009
More than a month has passed since Sydney Oracle Meetup #2. We shot some video, but it took me a while to process it and publish a few interesting pieces, but I finally got it all.
Ric Van Dyke’s presentation on tuning SQL queries using 10046 trace is available on the SOM website in the Files section (you must be a member). However, there were no material from Tanel Poder’s session — it’s title started with “Zero Slides…” and Tanel demonstrated live some of his secrets of productivity in Oracle troubleshooting. Luckily, my colleague, Andrey Goryunov, managed to shoot some of it on the video and I’m publishing here a couple fragments on the visualization of Oracle performance troubleshooting.
Make sure you are watching them in HQ on YouTube to see more details and if you like these videos, make sure you rate them.
PerfSheet is a very handy solution based on Microsoft Excel scripting and let you automate extraction and charting of any data you can extract from an Oracle database (and generally speaking, any other database). The best thing is that Tanel has put great efforts in it and made it available to everyone for free. One demo is worth many words so here we go:
Read the rest of this entry . . .
Posted by Sheeri Cabral on Jan 14, 2009
Wheel of protocol, turn turn turn.
Tell us the lesson that we should learn. (with apologies to the original source)
Writing a book comes with many challenges. For me, writing a MySQL book for MySQL beginners, who may or may not be database beginners, has fed my compulsion to research and test bizarre interactions.
Today’s lesson is on what protocol is used when connecting to a local mysqld instance on a non-Windows machine. The TCP/IP protocol is used by default when connecting on a Windows machine, and connecting from any operating system to a non-local mysqld instance. I am assuming the connections are being made by a command line client such as mysql, mysqladmin or mysqldump. Connections made via connectors such as Connector/J, an ODBC connector, DBD::mysql, etc are not covered in this post.
If you seem to be having trouble connecting, check your options against your intentions. Unexpected behavior is usually seen when your intention is to connect using TCP/IP, but the connection is using a socket file instead. Note the following behaviors:
Read the rest of this entry . . .
Posted by Vasu Balla on Apr 17, 2008
It is quite common for Oracle Tech support, while troubleshooting any 11i E-Business Suite Self Service Applications (SSWA) related error messages, to ask to enable debug logging in JServ configuration files.
The procedure to enable debug logging in JServ is to update following line in file $IAS_ORACLE_HOME/Apache/Jserv/etc/jserv.properties from log=false to log=true, and then bounce Apache using:
$ cd $COMMON_TOP/admin/scripts/$CONTEXT_NAME
$ adapcctl.sh stop
$ adapcctl.sh start
After the bounce, we start seeing debug messages in the log file $IAS_ORACLE_HOME/Apache/Jserv/logs/jserv.log.
Please note, the logfile’s and config file’s locations can be different from those mentioned above. In case you have a shared tech stack implemented, replace $IAS_ORACLE_HOME with $CONF_TOP/iAS.
The main problem with this procedure is the bounce of Apache. In cases where the client is not a heavy SSWA user and the issue isn’t affecting a significant number of users, then often we will be asked to wait until off-business hours to do the bounce of Apache. These delays can make your metalink SR hop between different Oracle support offices in different timezones, which can lead to delays in resolution of the issue.
Let’s have quick review of JServ configuration files which are of interest to us. jserv.conf — this is the configuration file of mod_jserv module in Apache. Here’s a snippet from jserv.conf: Read the rest of this entry . . .
Posted by Paul Vallee on Mar 11, 2008
Kenny Tilton writes a blog that is mostly about LISP programming, but today he posted about database troubleshooting, and he anecdotally illustrates and elaborates on a law of troubleshooting that I strongly agree with: Always solve the first problem. Based on the way this law is named, I suspect it is his own.
In a nutshell, any time there is a multiplicity of problems affecting an endeavour, simplify mercilessly until you have only one problem left. Then solve that one.
The corollary to his law is that “there only is the first problem.” I’m not sure I entirely agree with that one, but I will admit that that corollary is true at least 90% of the time, which is often enough to make it an incredibly useful insight.
Brilliant stuff! Read it.
