This is second session I attended in Tech 17. It was presented by Martin Bach and David Kurtz. The answer is eDB360. The session was in two parts with a presentation by Martin, then a demo with David.

Martin discussed the problems of doing a database health check, particularly for a third party company who may not actually have access to the database. It needs a standard approach, which is consistent across databases, and repeatable. Ideally performance data in AWR should be persisted for just over a year so that the performance of annual business cycles can be compared e.g., year end for financial systems.

On Wednesday 5th December, I attended Tech 17. While it is a pain to organise getting there and back, I found in previous years that it was useful for me to go and find out what is happening in the industry.

Cost Based Optimisation - The Panel Session

Panelists:

• Jonathan Lewis
• Christian Antognini
• Richard Foote
• Nigel Bayliss
• Maria Colgan

Slow Start

This took questions from the internet and the audience, so it is a bit variable. The question has to match something the panel can talk about. The first questions about the Autonomous database was disappointing in this regard as very little information has been released about it, and the Oracle employees had to stick to the company line, so couldn’t speculate.

The October Critical patch saw Oracle release

Patch 26743107: PT 8.55.19 PRODUCT PATCH LINUX DPK.

This is important to install because there was a serious security vulnerability in the performance monitor component which was easily exploitable over the network without authorisation.

However, once the DPK was installed, looking at the Weblogic home, we can see that the October critical patch

Patch 26519417: WLS PATCH SET UPDATE 12.1.3.0.171017

hasn’t been applied. It would be nice if it was delivered fully patched, but presumably Oracle’s internal time scales don’t allow this, so I will have to patch it myself.

Here is another note to myself about how to look at what sessions were doing over time.

The situation was that we saw a lot of blocking sessions during a performance test. The developer wants information about the blocking sessions. To do this we want historical information from v$session, which helpfully tells us the blocking session, and also the SQL being run. This can be sampled every so often using a simple script, but Oracle have already thought about this and created v$active_session_history which you can use if you have licensed the Diagnostics pack.

PeopleSoft Performance

Occasionally I have to diagnose a performance issue in PeopleSoft. This is a reminder to myself of the tools available and what I can check.

PeopleSoft Ping

This is a really useful tool because it gives real performance indications as to how the system as a whole is performing from the desktop to the database. The user can see the time taken at the browser, web server, application server and the database server for a simple query. When a slow response time is seen it is important to drill down to see what cause it. It could just be Windows downloading updates for example. PeopleSoft ping data is stored in the database used by the application in the table sysadm.ps_ptp_tst_cases. I used the following columns (See Dave Kurtz’ website for the rest).

Installing Apache and Ucam Webauth on Centos/RHEL7

Apache is pretty easy:

 yum install httpd

Done.

Ucam Webauth

It is hosted on github, but won’t be much use to anyone who doesn’t have a need to authenticate users with the University of Cambridge’s single sign on which is called raven.

I downloaded the SRPM from the raven page as suggested, and compiled it. The following packages are prerequisites. I used the follwing ansible task:

Database Links

Our PeopleSoft system suddenly started showing spikes in network usage. Users were complaining of slow performance. Enterprise manager shows big spikes in network waits. Strangely these don’t seem to be reflected in the SQL. The table on the left doesn’t have as much beige/grey as the one on the right.

Lets click on network and see what the waits really are. SQL*Net message from dblink.

Oracle Critical Patches

It was critical patch Tuesday this week. Because of the time differences between here and the USA we actually only get to find out about the critical patches on Wednesday, though there is a pre release announcement.

With software as complex as Oracles you can pretty much guarantee that there will be serious bugs somewhere in there which need patching every quarter.

Considering the types of organisations that run Oracle - the ones who can afford to pay the license fees, i.e. rich and powerful ones, you can be sure that someone is looking into what changed for each release, and how they can benefit from stealing or changing information.