Jump to Navigation

Recently created

A strange Java OPatch error

After installing a new version of OPatch on an Oracle database home, I got the somewhat mystifying error:

The java.library.path system variable is missing or invalid. Please set java.library.path with a correct value and retry the operation.

It turns out this is the error you get when you install a 32-bit version of OPatch into a 64-bit Oracle home.

Missing ports and rpcinfo

I was making an inventory of the bound ports on my server, when I encountered a rather strange situation: a high port that was not associated with any process.

The easiest way to find sockets like that is with:

MySQL: Check table engines in use

To determine whether tables in your MySQL database use MyISAM or InnoDB, you can use the following query:


This shows all engines used for each database. Most tables will use either MyISAM or INNODB, but there are other engines, like MEMORY, CSV and PERFORMANCE_SCHEMA.

Create database fails on package STANDARD

While scripting the creation of an Oracle database, I somehow kept getting errors during the CREATE DATABASE:

ORA-06553: PLS-213: package STANDARD not accessible

Very weird. Until I realized I was using a generic scripting function that issued a SET SERVEROUTPUT ON. It turns out that Oracle can not cope with that until you have loaded catalog.sql and catproc.sql.

xs4all VDSL with the Vigor 130

I am back on a slowish VDSL home connection. After getting used to high-speed fibre, this is quite a set back. My provider is xs4all. They provide a Fritzbox 7360 v2 modem. It used to be that you could set these to bridge the VDSL signal to your ethernet, but this is no longer possible for recent firmwares.

Talking to Grid Control

And suddenly, Firefox did not want to connect to Oracle Grid Control anymore.

The error message displayed was Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap). Google was not immediately useful (suggesting things like turning off SSL).

MySQL: Administering replication

Replication threads

Replication uses two slave threads. One is the I/O thread: it connects to the master server, downloads transactions and writes them to the relay logs. The other is the SQL thread: it reads transaction from the relay logs and executes them.

Provided the network connection between master and slave is stable, any bottlenecks are in the SQL thread. On a very busy system it can lag behind the I/O thread.

MySQL: Binlogs

You have to use binlogs for three reasons: when this server is a master to a slave, when this server is part of a replication structure using GTIDs or when you want to be able to do point-in-time recoveries.

A slave uses the binlogs of the master for replication. If you are not using GTIDs, the master binlogs are read sequentially and each non-filtered transaction is applied. The position in the master binlogs of the slave is thus very important.

MySQL: Restores, binlogs and GTIDs

Part of a backup strategy is deciding how to handle the binlogs. When using GTIDs this is even more important. This page assumes you have enabled the binlogs in the server you backup.

Binlog handling by MySQL

When MySQL starts, it looks for existing binlogs.

Whether it finds existing binlogs or not, it will start a new binlog file. It will get number 000001 if no binlogs were found, or the next highest number if there are already binlogs.

MySQL: Roll forward (PITR)

After restoring a backup it is possible to roll forward your databases by applying the binlogs. This means that all committed transactions between two points in time are executed again. A roll forward  can happen on the original server the binlogs were generated or on some other server.

A roll forward is executed by translating the binlogs to plain SQL statements and executing them. This means that if you try to apply binlogs to a database some statements may fail, if the start situation was not entirely correct.


Subscribe to Recently created

by Dr. Radut