Search

Top 60 Oracle Blogs

Recent comments

Oracle

V$MYSTAT delta values

Here is a little script I use from time to time to look at V$MYSTAT values and displaying on one line a set of statistics with their delta value between two calls.

The first script, _mystat_init.sql, initializes the variables. The second one displays the values, such as:

SQL> @ _mystat_diff.sql
 
db block changes redo size undo change vector size redo entries
---------------- ---------------- ----------------------- ----------------
57,371 15,445,852 6,111,608 37,709

A look into Oracle redo, part 3: log writer work cycle overview

This is the third part of a series of blogposts on how the Oracle database handles redo. The previous part talked about the memory area that stores redo strand information: https://fritshoogland.wordpress.com/2018/02/05/a-look-into-oracle-redo-part-2-the-discovery-of-the-kcrfa-structure/.

The single most important process in the Oracle database for handling redo is the log writer, which primary task is flushing the redo information other Oracle database processes put in the public redo strands to disk. Now that we have investigated the public redo strands and concurrency (first part) and kcrfsg_ and the KCRFA structure (second part), it seems logical to me to look at the log writer.

Server process name in Postgres and Oracle

Every database analysis should start with system load analysis. If the host is in CPU starvation, then looking at other statistics can be pointless. With ‘top’ on Linux, or equivalent such as process explorer on Windows, you see the process (and threads). If the name of the process is meaningful, you already have a clue about the active sessions. Postgres goes further by showing the operation (which SQL command), the state (running or waiting), and the identification of the client.

Postgres

By default ‘top’ displays the program name (like ‘comm’ in /proc or in ‘ps’ format), which will be ‘postgres’ for all PostgreSQL processes. But you can also display the command line with ‘c’ in interactive mode, or directly starting with ‘top -c’, which is the same as the /proc/$pid/cmdline or ‘cmd’ or ‘args’ in ‘ps’ format.

Post GI / RDBMS Installation Configuration Steps

Introduction

This is the third article in a series of blog posts on building a test environment to closely match a Production environment so we could then upgrade the test environment from Oracle Database 12.1 to Oracle Database 12.2. In the first post, I covered performing a silent installation of the grid infrastructure software. In the second post, I followed that by performing a similar silent installation of the RDBMS software. In this post, I’ll be covering the rest of the configuration work for this environment.

Silent Installation of the RDBMS

Introduction

In my last post, I walked you through the silent installation of the Grid Infrastructure software. In this post, we’re moving on to the next stage of the environment build for this customer, doing a silent installation of the RDBMS software.

RDBMS Installation

The silent installation of the RDBMS software is fairly similar to that of the Grid Infrastructure software. You create a response file that contains the responses you would normally provide interactively, and use that with the runInstaller program to perform the installation. The response file I used for that is as follows:

Silent Installation of Grid Infrastructure

Introduction

Recently I had a requirement to install the Grid Infrastructure and Oracle RDBMS on a completely new VM. The customer I was doing this work for wanted to take a copy of their Production environment to another server so they could test an upgrade of their existing environment from Oracle GI / RDBMS 12.1 to 12.2. So they built a VM for me, copied the 12.1 installation media for both GI and the RDBMS and said “Go for it!”

I decided to log everything I did and write a series of blog posts based on my experience, in case it was of use to others. There were a few issues I needed to deal with for this customer. Some of those issues were:

12cR2 PDB archive

In 12.1 we had the possibility to unplug a PDB by closing it and generating a .xml file that describes the PDB metadata required to plug the datafiles into another CDB.
In 12.2 we got an additional possibility to have this .xml file zipped together with the datafiles, for an easy transport. But that was not working for ASM files.
The latest Release Update, Oct 17 includes the patch that fixes this issue and is the occasion to show PDB archive.

Here is Oracle 12.2.0.1 with Oct 2017 (https://updates.oracle.com/download/26737266.html) applied (needs latest OPatch https://updates.oracle.com/download/6880880.html)
With a PDB1 pluggable database:

[oracle@VM106 ~]$ rman target /
 

RMOUG Training Days 2018

So Training Days is coming up in two weeks.  You haven’t registered to attend?  How you feeling about that?

Rocky Mountain Oracle User Group, (RMOUG) has the largest Oracle user group grassroots conference each February.  For the 2018 year, we decided to shake it up with:

JAN18: Database 11gR2 PSU, 12cR1 ProactiveBP, 12cR2 RU

If you want to apply the latest patches (and you should), you can go to the My Oracle Support Recommended Patch Advisor. But sometimes it is not up-todate. For example, for 12.1.0.2 only the PSU is displayed and not the Proactive Bundle Patch, which is highly recommended. And across releases, the names have changed and can be misleading: PSU for 11.2.0.4 (no Proactive Bundle Patch except for Engineered Systems). 12.1.0.2 can have SPU, PSU, or Proactive BP but the latest is highly recommended, especially now that it includes the adaptive statistics patches. 12.2.0.1 introduce the new RUR and RU, the latest one being the one recommended.

Where in the World is Goth Girl- Cleveland Edition

I’ve returned from SQL Saturday Cleveland after presenting “Linux Performance Essentials for the SQL Server DBA”.  The event had 30% women speakers, which is incredible for a technical event.  I’m thrilled with the attendance and although my session went through a lot of Linux in an hour, people didn’t leave looking like their brains were going to explode, so mission accomplished.