Being forced to work with MySQL Databases, not every Web Developer is familiar with databases in general.

Now the good news is that when working in a LAMP (Linux, Apache, MySQL and PHP) environment you do not really need to have deep knowledge about relational databases to succeed.

Most tools like CMS do a full automated setup for you and the only knowledge it needs to have starting with them, is the server and database name and finally the login credentials (username/password) to access it.

Just later on the one or other maintenance work will occur and you will feel the need of having some nice and neat database interface to work with. Knowing about this need today I will recommend you a few tools and you should feel free to choose one or each of them based on your platform and taste.

The first tool I will recommend you is called phpMyAdmin. It is written in PHP and as a so called browser tool it works platform independent and flawless in all common browsers. Very often being offered by hosting providers it is mostly already part of your hosting package and easy to access and use. Coming along with all necessary options like browsing and navigating through your databases, it also offers a SQL interface and the often necessary export/import options. Personally it is my favorite tool to work with.

Once you are familiar with phpMyAdmin, phpMyBackupPro is another very similar tool you might find it worth to look at. Also browser based it is mainly written for interactive exports and imports, but can get also use for scheduled automatic backups.

For Windows platform only I would like to recommend you a tool called MyDB Studio. Coming along with a well designed interface it offers all features you need and the license it needs is given away for free in case you only use it for private and non commercial interests. It just needs you to give them a valid email address and the key is emailed to you quickly after.

And now finally and last in case you are such a Macintosh guru, I would like to recommend you CocoaMySQL. It does a similar great job like the others and can get used right away after the installation has taken place. What I like is the console view of is, showing you all command issued during the past and looking at it you might even learn some SQL (Structured Query Language).

Working with Oracle, using TEMPORARY tablespaces with tempfiles is best practice today. Unfortunately there are two situations in which you may encounter trouble as for the tempfiles are missing and sort operations do no longer succeed.

Curiously and based on the fact that Oracle does not record checkpoint information in tempfiles, Oracle can even start up a database with a missing tempfile.

DBW0 will write to a trace file indicating the tempfile is not found, but the database opens normally and later on only sort operations will fail with some of the Oracle Errors ORA-01116, ORA-01157 and ORA-25153.

Such situation can be caused by simply the OS file related to a tempfile cannot be not found anymore or the logical tempfiles attached to the TEMPORARY tablespace do not exist anymore.

This can happen in case the tempfile was located on a disk that crashed, had a bad controller, or some other type of media failure, a recovery or cloning of the database was done before and/or finally and purely caused by human error.

Solution : Drop the logical tempfile and add a new one

SQL> alter database tempfile ‘/oracle/oradata/SID/tempfile.tmp’ drop;

Database altered.

SQL> select tablespace_name, file_name from dba_temp_files;

no rows selected.

SQL> alter tablespace temp add tempfile ‘/oracle/oradata/SID/tempfile.tmp’ size 100m;

Tablespace altered.

When transferring data from one server to another – maybe for backup reason – most people use tar to create an archive. Then they copy it to the new server and untar it or leave it as a tarfile as backup.

Working with UNIX and using a trick  you can transfer it with compression and speed up the whole transfer time a lot.

Using the output result of  a command directly as the command line input of a second command  using a  Unix Pipe the need of writing it down to disk first no longer exists. Finally accessing the remote system though a ssh tunnel will even transfer the compressed data over the network within one single step.

Invoking the following single command will transfer all your data within sourcedirectory an Server B and immediately store it locally  on Server B within a compress archive:

ssh username@hostname “cd /sourcedirectory/ ; tar czf – .” > /targetdirectory/filename.tgz

While the following variation:

ssh username@hostname “cd /sourcedirectory/ ; tar czf – .”> /targetdirectory/filename.tgz| tar xvf –

will directly extract it again for you on the your local system.