sabaTEL.net

Java, MySQL, Avaya

Deleting Old Log Files

Well I’m not going to say how useful it can be to analyse the log files of our application, in particular if you are troubleshooting a fault. Sometimes, those logs are big, very big, and not that flexible in terms of rolling over.
In those cases external tasks need to be setup to avoid running out of disk space.
I’m presenting a script that I’m using in order to do this task for Microsoft environments.

It will be launched via a Scheduled Task running a batch file with this content:
cscript C:jboss-1serverdefaultDelOldLogs.vbs

Advertisements

June 13, 2011 Posted by | Microsoft | Leave a comment

PROFILER and EXPLAIN

If we want to improve the performance of a query, these 2 guys can help us in order to find out bottlenecks, but remember the most important job comes before, designing appropriately the database.

Times described at
http://dev.mysql.com/doc/refman/5.5/en/general-thread-states.html

June 7, 2011 Posted by | MySQL | Leave a comment

InnoDB Isolation Levels, Multi-Versioning and Concurrency

When multiple clients run transactions concurrently, three problems that may result are dirty reads, non-repeatable reads and phantoms.

  • A dirty read is a read by one transaction of uncommitted changes made by another.
  • A non-repeatable read occurs when a transaction performs the same retrieval twice but gets different results each time.
  • A phantom is a row that appears where it was not visible before.

InnoDB implements 4 isolation levels that control the visibility of changes made by one transaction to other concurrently executing transactions:

  • READ UNCOMMITTED allows a transaction to see uncommitted changes made by other transactions. Dirty reads, non-repeatable reads and phantoms.
  • READ COMMITTED allows a transaction to see changes made by other transaction only if they’ve been committed. Non-repeatable reads and phantoms.
  • REPEATABLE READ ensures that a transaction issues the same SELECT twice, it gets the same result both times.
  • SERIALIZABLE completely isolates the effects of one transaction from others.

InnoDB operates by default in REPEATABLE READ mode. The isolation level can be setup at startup time:
[mysql]
transaction-isolation = READ-COMMITTED
But it can also be setup dynamically for a running server to different levels:
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

June 6, 2011 Posted by | MySQL | Leave a comment

InnoDB Engine

  • Similar to the MyISAM and MERGE Engines seen so far. The interesting features appear with the disk management. Each InnoDB table is represented by and .frm format file as well as data and index storage in the InnoDB Tablespace. By default a single tablespace will be used by different tables.
  • Supports transactions with commit and rollback. It provides full ACID.
  • Provides auto-recovery after a crash of the MySQL server or the host where it runs.
  • Performance wise it seems better than the last 2 Engines, but here you can get deadlock.

June 2, 2011 Posted by | MySQL | Leave a comment

MERGE Engine

Basically, MERGE is a copy of MyISAM, allowing us to exceed the maximum MyISAM table size. MERGE will be slower to read indexes because MySQL has to search the indexes of multiple tables.

The book example:

I’m still unsure about the error I’ve got, due obviously NorthAndSouth is not a MyISAM table.

May 30, 2011 Posted by | MySQL | Leave a comment

Which Storage Engine is my table using?

There are different ways to find that out, below these 2 examples:

We could access the INFORMATION_SCHEMA and get all Engines being used at our database:

May 28, 2011 Posted by | MySQL | Leave a comment

MyISAM Engine

Main characteristics of the MyISAM Engine at MySQL:

  • On disk each table uses 3 files: City.frm (format), City.MYD (contents), City.MYI (index).
  • Has the most flexible AUTO_INCREMENT column handling.
  • Can be used to setup MERGE tables.
  • Can be converted into fast, compressed, read-only tables to save space.
  • Supports FULLTEXT searching and spatial data types.
  • Queries for MyISAM use table-level locking. Deadlock cannot occur, but performance can be reduced in environments with mix of read and write queries.
  • To workaround that high level of locking we can use a query modifier such as LOW_PRIORITY or HIGH_PRIORITY. Inserts into a table can be buffered on the server side until the table is ready by using INSERT DELAYED.
  • Storage format is portable.
  • Extras like specify the number of rows that you a MyISAM table should hold.
  • Loading data into an empty table, you can disable indexes. LOAD DATA INFILE does that already.
  • If you run out of disk space while adding rows to a MyISAM table, no error occurs. The server suspends the operation until the space becomes available.

So far it looks the most flexible, and that’s probably why is the default storage engine, the main cons would be the table-level locking in certain scenarios.

May 28, 2011 Posted by | MySQL | Leave a comment

Avaya AES Health Checker

At work, there are some tasks that you do as a routine. One of them for me is to check the AES servers, when there is a fault for one of our customers that use softphone or any other bespoke application.

The Avaya AES server or Application Enablement Services server is basically the machine encharged of enabling that extra functionality the Avaya PBX offers on top of Telephony to 3rd party applications like softphones, call tagging, call back, …

To minimize the time, doing those checks I’ve started developing a new script in Python, as from AES 5.2 it’s included. Probably, at the moment I want to keep it small, running only basic commands, but maybe later I will include some log parsing.

May 27, 2011 Posted by | Avaya, Python | Leave a comment