Simon Krenger

One thing DBAs regularly do is to gather information on the schemas in the database for reporting. So we want to know how many rows there are in the tables of the schema “SIMON”. When doing so, one is tempted to query the DBA_TABLES view:

SQL> SELECT table_name, tablespace_name, num_rows
  2  FROM dba_tables WHERE owner='SIMON' ORDER BY num_rows DESC;

TABLE_NAME                     TABLESPACE_NAME                  NUM_ROWS
------------------------------ ------------------------------ ----------
HUGE_TABLE                     DZ_DATA01                         8227990
[..]

However, if we query the table directly, we get a different result:

SQL> SELECT count(*) FROM simon.HUGE_TABLE;

  COUNT(*)
----------
   8230310

Why is that so? When reading through the description of the ALL_TABLES view, one finds the following note:

In the past weeks, I was responsible for setting up a new JBoss Application Server for a customer. One thing I had to do was to enable authentication via the customers existing Active Directory for SSO (Single Sign On).

When fiddling with authentication, one is always happy to find examples of existing installations. In this post, I give an example of how to configure LDAP authentication (in this case with Active Directory) in JBoss. While you can find extensive documentation on the JBoss website, I always like it if there is a specific example provided, so here it goes:

login-config.xml

So there I was. I just installed Nagios on a brand new Debian (6.0.3) host, I was greeted with the following error message after logging into the Nagios web interface and clicking a link that uses external commands:

Error: Could not stat() command file '/var/lib/nagios3/rw/nagios.cmd'

What? Well, after making sure my configuration is correct, I figured that this must be some kind of permission problem…

Well, I was quite busy before the holidays, but here is another post I just keep for my reference.

For each database, I believe it is important to automate database shutdown and database startup. This way, in case of an emergency, a systems administrator can start and stop database services without the need for a database administator. Oracle provides an excellent article on this topic, but the Oracle documentation is quite generic. So I hereby provide a step-by-step guide for Red Hat Enterprise Linux (RHEL).

When writing an application in PHP, I like to use Justin Vincents ezSQL for database access. ezSQL allows you to write your query and get your results as a PHP object, as shown in the following example:

// Select multiple records from the database and print them out..
$users = $db->get_results("SELECT name, email FROM users");
 
foreach ( $users as $user )
{
            // Access data using object syntax
            echo $user->name;
            echo $user->email;
}

So one common task you might want to do is to present the retrieved result as a table. While the ezSQL library features a debug() method, this should obviously only be used during development. So if you want to display your result as a table, you’ve got to do it yourself and I hereby provide a snippet of code on how to do it…

So after you’ve fetched your result from the database you can use the following method to print a HTML table with your results:

For my studies, I bought a MacBook Air with the swiss keyboard layout. The Air is really nice to carry around, since it is light, thin and features a battery that lasts for more than 6 hours of light work (e.g. working in Eclipse).

However, one thing I did not really like was the circumstance, that Apple uses a non-standard keyboard layout for its notebooks. When you are typing letters this will most likely not bother you, but as soon as you start to use special characters (such as []{}~\), you’re in trouble.

So I searched for a way to restore the standard keymap for the swiss german keyboard. Luckily, I stumbled upon this great application called Ukelele, which allows you to modify the keymap for Mac OS X.

Today one of our developers came to me to discuss a problem and I wanted to show him something on one of our Linux machines. To check a process, I ran pstree and noticed that the formatting of the output was all wrong:

simon@atlas:~$ pstree
initââ¬âacpid
     ââapache2âââ10*[apache2]
     ââatd
[..]
     âârsyslogdâââ3*[{rsyslogd}]
     ââsshdââ¬âsshdâââbashâââping
     â      ââsshdâââbashâââpstree
     â      ââsshdâââsshdâââsh
     ââudevdâââ2*[udevd]

This is obviously just a cosmetical problem and the output is quite hard to read. When encountering something like this, the first guess would be that the encoding is somehow wrong. When checking the environment variables with env, we find that LANG is set to “en_US.UTF-8”.

For a proof-of-concept, I had to install a new Mantis Bug Tracker instance and after finishing the installation, the login screen greeted me with the following warning:

SYSTEM WARNING: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead

The solution is amazingly simple. The only thing that I needed to find out was that this is a PHP error and not a MantisBT error. So after that was settled, I went on and just followed the instructions given by the warning:

For an university assignment, I had to implement a recursive function to calculate the digit sum of a given number. I place my solution here for my own reference:

public static int digitSum(int n) {
	if(n < 10)
		return n;
	else
		return n % 10 + digitSum(n / 10);
}

This code can also be found in the GitHub repository that I am keeping for university: ChecksumTool.java

When comparing floating-point numbers (float, double) in Java, we quickly discover that we get roundoff errors. This has to do with the limited precision of Java floating point variables. The following code example shows the problem at hand:

double r = Math.sqrt(2);
double d = r * r - 2;
if (d == 0)
	System.out.println("sqrt(2) squared minus 2 is 0");
else
	System.out.println("sqrt(2) squared minus 2 is not 0 but " + d);

Theoretically, d should be 0, but because we have limited precision (see the documentation on primitive data types) there will be a difference:

sqrt(2) squared minus 2 is not 0 but 4.440892098500626E-16

One possibility to circumvent this problem is to define a constant value (the following example uses EPSILON). We then check if the difference is smaller than that constant value. Since we received a very small number (4.4E-16) above, we can use 1E-14 as the value of our constant: