Why start using Java in the database?

I have had a couple of situations recently where using Java in the database might come in handy.

One is replacing a self-hosted database with one on the cloud. The provider gives access to the database, which means remote procedure calls don’t work - the provider doesn’t give access to the underlying OS, they provide the database as a service. This means the remote procedure call will have to be replaced in some way.

I expect the question after the last I/O article is: How did we make our server go faster?

Things That Did Work

Looking at the AWR report, I could see the main problem was that async I/O was slow. We set

1

filesystemio_options='SETALL'

in the spfile, and this helped a lot. As I understand it, this enables asynchronous I/O, which means that rather than waiting for confirmation after writing, the database keeps on sending data to the SAN. This sped up the I/O by a factor of about 3.

How Does a Database Use IO?

We have a shiny new database server. We ran some tests on it, and found it was about the same speed as the old one. Worryingly the IO system seemed to be struggling to keep up with the load.

In case you don’t know, IO is short for Input/Output, and is used to describe the use of a hard disc, or similar storage. We all know that hard discs are slow compared to memory, but for a database to work well, the IO system needs to be able to keep up with the work the database is doing. Otherwise the database will eventually appear to lock up.

We use a Virtual Private Network - a VPN to access all our work servers. But we use MS teams for meetings, and our VPN admin asks us not to to push loads of video over the VPN. So what to do? Disconnecting from the VPN every time a call came in got old pretty fast. And what do you do if you want to show a colleague something which required VPN access?

A colleague had created a new service operation in peoplesoft integration broker, but it wasn’t working. After a lot of investigation, and a call to Oracle, we found the cause was SNI: Service Name Indication. This is a facility which allows several different hostnames to be on the same IP address, but still listen in HTTPS.

It seems the Integration Broker converts the hostname to an IP address before trying to contact the remote site. The problem is then that the remote site doesn’t know which website it wishes to talk to, and this causes a handshake failure. The messages in the logs are not helpful to say the least.

Silent install

A new feature of 8.58 is the silent installation. The documentation says you can run a command such as:

1
2
3
4

./psft_dpk_setup.sh \
  --silent \
  --response_file=response.txt \
  --customization_file=psft_customizations.yaml

The customizations file is optional, but I decided this time around to use it as much as possible to create a system as close as possible to what I wanted to end up with. So I copied the file from <psft_base_dir>/dpk/puppet/production/data/psft_customizations.yaml and edited it to my satisfaction. <psft_base_dir> above is whatever was specified when the installer asked interactively, or in the response file. This means I had to do a test install before I could do a proper one, but that is fine.

We recently purchased a new database server. We ran a performance test which our brilliant testing team have put together and found out the system with the new server was slightly slower than the system with the old one. The testing team was happy that the test was a pass - the users wouldn’t notice the difference. However, new servers are supposed to be quicker than old ones, so I was disappointed. I investigated a little further, and found that the AWR report showed there were more waits on IO on the new hardware than on the old.

Redo Investigation

I was investigating a performance issue on new hardware and installed SLOB to do so. I discovered in the AWR report, that the redo generated per transaction was around four times that in development.

I checked everything I could think of, including copying the parameter file from development to the new hardware and using that, but the redo stayed stubbornly high. I asked the oracle-l mailing list for ideas. Jonathan Lewis responded suggesting the high redo could be caused by the following: