What Version of Weblogic Is It?

Ever wonder what version of weblogic is on your server? Here is how to find out.

-------------

First, set the environment variables in $DOMAIN_HOME

Overcoming the Oracle Apps R12 Error APP-FND-01542 on 64 bit Redhat 5.5

Symptom:

Ever try to login to Oracle Apps R12, and get the error APP-FND-01542 on 64 bit Redhat 5.5?

APP-FND-01542
The applications servers is not authorized to access this database.

Here is how to solve it.

Oracle Apps R12 - Let Me Count the XML Files

Just how many XML files does Oracle Apps R12 use?

Review of Colasoft - Network Activity Analyzer - It's Awesome!

The other week, I downloaded Colasoft's Network Activity Analyzer, and took it for a test drive. Colasoft is a fabulous network analyzer, intuitively obvious and such a pleasure to work with. It installs and works in a few minutes. Highly recommended!

I was prompted to download it, because I've often wondered about network activity on my machines.

In addition to seeing the total network activity on the machine, I'd like to see the network activity by each browser window. And further, by each tab in each web browser. So far, I haven't found a product to do this. If anyone knows of a such a product, please leave a comment. I'd love to see the product.

Using NMAP To Find The Ports For Oracle Apps, OBIEE, Listener

Not finding a port with netstat? Nmap finds what netstat does not. Nmap can also point out your servers' vulnerabilities.

Overcoming Oracle Apps R12 FRM-92101 Error On Redhat Linux 5.5

Have you ever got the Oracle Forms error, FRM-92101 with Oracle Applications R12 on 64 bit Redhat Linux 5.5? Here is how to overcome it.

Firefox, Oracle Apps, Java plugins, on 64 Bit Redhat 5.5

When using Firefox on Linux, have you ever got the aggravating message concerning oaj2se.exe, or NPX_PLUGIN_PATH? Here is the solution.

From what I have read, on Linux, using the Firefox browser for Oracle Forms is not certified. At least it wasn't in the past. Bizarre.

-----------

Symptom:

On Redhat Linux, you try working with an app such as Oracle Apps, and navigate to where the software takes you. But you suddenly get the error message:

In order to access this application, you must install the J2SE Plugin version 1.6.0_07 on your client and NPX_PLUGIN_PATH environment variable is set before starting Netscape. To install this plugin, click here to download the oaj2se.exe executable. Once the download is complete, double-click the oaj2se.exe file to install the plugin. You will be prompted to restart your browser when the installation is complete.

The problem is, oaj2se.exe is an executable that only works on Windows.

Oracle database tuning and being "nice"

I was reading this blog about the Linux "nice" command
http://prodlife.wordpress.com/2008/04/09/yet-another-nice-myth/

which was referenced in another blog about 100% CPU utilization.
http://hoopercharles.wordpress.com/2010/02/05/faulty-quotes-6-cpu-utilization/

Both reminded me of experiences while I was researching how to insert one billion rows per day that I'd written about in my first post.

I'd started out around 6K rows per second insert speed. With more research I was able to get the insert speed up to about 9k or 10k per second. Usually I ran Oracle data dictionary queries to monitor the performance and other activity. Then I started using unix commands as well.

On the dedicated database server, there were some unix processes taking up the majority of the cpu. So all the CPU were running at least 99%, 100% of the time.

It turned out that the unix admin was, on the company servers, privately running processes on the "spare" cpu using "nice". The processes had to do with something astronomical, calculating things with brute force algorithms for a non profit.

I said that this was slowing down Oracle, and my testing. He insisted that since it was running at the lowest priority of nice, it could not possibly be slowing down the database. Intuitively, I knew this was wrong.

Eventually, we got those astronomical calculation processes off the server. The insert speed immediately went up to 13k rows per second. This was a very significant increase in performance.

Conclusion: the extra "nice" processes on the CPU had in fact been slowing down the Oracle database.

So, given these experiences, on multi user, multi tasking Oracle, I don't think it's a good idea to have 100% CPU server utilization for sustained periods of time. Especially if there are a lot of inserts or updates (reads and writes to the hard drives) occurring.

Oracle Performance Tuning

I guess the first entry to start my notes should be the one thing I’ve already done a lot of writing on.

Since I started working with the Oracle database in 1995, I've always been very concerned about tuning, performance and response times. Even with the poor software and hardware that we had, I still had to make it work fast. Even though much of the conventional wisdom at the time was to just buy faster hardware, this was never an option at the companies where I worked. I made things go fast by doing what I could do; changing the code, not by buying new hardware.

Later, I was promoted from a developer, to a DBA, and a unix admin. A new job in year 2000 - 2001 gave me a daunting challenge. The startup wanted to insert ONE BILLION rows of data into an Oracle 8i database, every day. Which is about 11,000 rows per second. This is not difficult now, but with year 2000 hardware and Oracle 8i software, I was only getting about 6,000 row inserts per second to begin with on the hardware I had. I researched how to do this all day and evening. It took me very deep into Oracle internals and storage.

One of my “few” discoveries was that a number of the tuning paradigms at the time, after I tried them, really made absolutely no significant difference at all. Some of these concepts were whether we used RAID 0, 1, or 5, and hit ratios in Oracle's buffers. My rigorous experiments where I modified only one variable at a time, such as the RAID setting, produced no difference in the data results at all. The data results were not supporting the paradigms.

For those of you who are firm believers that RAID 0 or 1 is faster than RAID 5, that may be true at the hard drive level. However, the slowest part of doing those 11,000 inserts on average per second was in fact Oracle's Log Writer (LGWR). The LGWR was slower than the hard drives that wrote the log to disk. Even those disks set at RAID 0 or 1. While Oracle can have many parallel server processes reading the data, and many database writer (DBWR) processes writing the data, there is only one log process. And, it MUST be sequential. And it must work without fail, otherwise the Oracle database stops. When we used Spotlight on Oracle during these heavy insert processes, the indicator for the log writer turned red, red, red. Eventually, I was able to get 13,000 inserts per second. But it wasn’t easy. And it was not achieved by the paradigms that I had had been advised to do.

Fortunately, since then, a number of Oracle researchers such as Tom Kyte, and Cary Millsap did experiments that exposed the flaws of some of the original paradigms of Oracle tuning. They made perfect sense to me. Google for: “Why a 99% buffer cache is NOT Ok”

A few years later, I presented at the Oracle User's Group on PLSQL and SQL tuning. There was not much theory. It was pretty much all case studies on how I dramatically sped queries up from hours, to minutes. And sometimes, hours to seconds. I've received compliments in emails from Germany, Italy, and India about my ideas. Many websites are referencing it around the world. You can google my name, or find the presentation here:

home.earthlink.net/~rodger22/plsql.htm

I resonate a lot with the experts Tom Kyte and Cary Millsap. Don’t speculate. Do the experiment, show me the data, and analyze it. Draw conclusions based on the data, not the other way around. If you have not read any of Tom Kyte’s or Cary Millsap’s work, it’s highly recommended. Do look them up.

Method-r.com

Asktom.oracle.com