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