Archive pour la catégorie ‘Oracle’

mysqlslap et supersmack, deux outils de benchmark pour MySQL

Lundi 7 juillet 2008

Il est parfois reproché au serveur MySQL de ne pas fournir suffisamment d’outils de benchmark / profiling concernant les requêtes ou le fonctionnement du serveur lui-même. Des commandes telles que SHOW STATUS (affiche l’état du serveur à un instant t), ou bien encore EXPLAIN (plan d’exécution de la requête SQL) permettent néanmoins d’obtenir de précieuses informations.

Ceci étant dit, comment s’assurer que son serveur MySQL tiendra la charge ? 1000 requêtes /s en insertion sont prévues le jour de la sortie de votre prochain service internet : votre serveur sera t-il capable d’y faire face  ?

Les deux outils présentés aujourd’hui permettent de simuler la charge reçue par le serveur MySQL en fonction de différentes paramètres dont le nombre de connexions simultanées et le nombre de requêtes par utilisateurs. Avec de tels outils, vous pouvez par exemple tester mysqlslap sur une de vos requêtes clé, visualiser comment celle-ci réagit sous différentes configurations, et visualiser un « score » à base de temps d’exécution. Une fois ce « score » récupéré, comparez-le avec celui que vous obtiendriez avec la même requête modifiée par vos soins, avez-vous progressé ?
Lire le reste de cet article »

Vous avez une question? Nous y répondons!

Samedi 5 juillet 2008

Un peu dans l’idée de asktom.oracle.com, le très célèbre site de Tom Kyte, grand gourou Oracle, nous lançons une sorte de Yahoo! Question – Réponse sauce DBNewz. Suite à l’idée d’Arnaud et sa série dont vous êtes le héros, nous vous invitons à poser une question par émail à question@( vous connaissez le domaine )  et nous y répondrons.

Quelle est la différence avec un forum? Nous retenons les meilleures questions et nous écrivons un article avec la dite question et sa réponse. Si vous ne voyez pas votre question, c’est que nous n’avons pas encore eu le temp d’y répondre…

A très bientôt!

PS: Cette adresse peut aussi être utilisée si vous constatez un problème sur le site…

Les SSD (Solid-State Drive) : une technologie d’avenir pour nos SGBD ?

Mardi 13 mai 2008

Modifier une petite ligne dans le fichier de configuration de son SGBD et obtenir les performances souhaitées, c’est possible… si vous êtes chanceux. La performance globale d’un SGBD repose en effet sur un ensemble de briques, logicielles ou matérielles, qui une fois empilées correctement forment un ensemble cohérent (et performant) : la seule étape du fichier de configuration ne suffit pas.

Dans un de ses récents billets, Matt Yonkovit a déclenché une série de réflexions intéressantes à propos de l’impact des performances des disques durs sur l’ensemble du SGBD.

Selon lui, les problèmes de performance au sein d’un SGBD sont la plupart du temps relatifs aux disques durs et notamment au nombre d’I/O (Entrées/Sorties) qu’ils sont capables de traiter par seconde (IOPS).

Comparés aux processeurs actuels capables de prendre plusieurs milliards de décisions par seconde (Ghz) et aux mémoires vives dont les temps d’accès se mesurent en nanosecondes, le temps d’accès d’un disque dur se compte encore en millisecondes… Difficile de lutter contre des éléments purement électroniques quand on est constitué d’éléments mécaniques en mouvement (têtes de lecture, plateaux…).

Lire le reste de cet article »

Some thoughts on Agile Data Development

Mardi 11 décembre 2007

Many things in the current IT world are based around hard facts, solid experience and studied techniques. Unfortunately this tends not to be the case when it comes to application developers making database decisions. This is not a criticism of application developers per se, their expertise lies in the app technology, but more a problem with development process and a misunderstanding of the role of the database as the underpinnings of data oriented (as opposed to object oriented) application architecture.The general process of modern agile application development proceeds along fairly set lines of iterative feature based and hopefully test driven development. This approach of getting something working with a suite of tests around it which enable rapid refactoring and rapid development run counter to most Big Design Up Front (BDUF) methodologies, most notably the much maligned waterfall model and the general approach taken to most database driven methods. To truly be an agile database developer in this brave new development world implies a level of clairvoyance beyond most of us, and requires an understanding of future application direction and projected data growth which is beyond that which can be expected of application developers and their product managers. To ignore this difference in requirements of the agile developer and the data modeller/DBA will invariably lead to scalability and performance issues as the project moves forward through its multiple iterations.

We are not saying here that the focus and philosophy of the agile development team and that of the database designer/administrator are incompatible, more that there is a difference in the needs and aims of the two groups and that this difference needs to be recognised as such. This is not always the case in the necessary drive to shift development paradigms. The larger the project, the more apparent this becomes. Changing code is not the same as changing data. A database at the core of a complex multi tier application will usually be supporting many different access paths, from the OLTP requirements of a running user driven application to the reporting requirements of management and maintenance as well as a suite of custom administration interfaces, data feeds in and out as well as the requirements for failover and disaster recovery, and refactoring, recoding and changing requirements is not as simple as that of single parts of the overall codebase.

While there are database methodologies to support agile development, generally the current processes have database design/deployment/administration as worrying separate, and the realms of all the pieces of getting a product from the back of a restaurant napkin to global server deployment need to incorporate the whole iterative development process. We should not be in the position of giving the DBAs the code to deploy when the iterative cycle ends. This is simply unacceptable from an architecture and process point of view. What we have here is a series of failures in using the best people for the job.

As mentioned above, application developers are not generally the best people to be structuring and modelling the data. Data structures, no matter how well abstracted, are fundamentally tied to the underlying technology. Sensible design and architectural decisions can only happen if the data specialists are incorporated into the agile development teams themselves. We can, and need, separate database administration teams, but also, these teams must be part of, or have significant input into the development process, else all roads lead to project misery, to poor use of software/hardware and the continuation of the ignorance loop, as mistakes in data structure and design are rarely fed back up to the original designers. Adding features to code and refactoring as we go works for code, it rarely works in practice for data. It is not so much the new features that is the problem, it the short-termism which the process unconsciously encourages which lies at the heart of the problem. Large data volumes require a degree of foward planning that is often lacking from our short Sprint focused design decisions.

Ignoring data modelling disasters, most projects start off with a fairly well understood and structurally sensible data structure (bear with me here) for the first few iterations of the system. These first set of requirements generally have the data model supporting them happily. The issues only usually really arise as the codebase and feature list grows, along with the growing datasets. Data structures that support smaller volumes of data do not necessarily scale linearly and a lack of understanding of the changing nature of the system will cause problems for the future of the application due to information not flowing back from the DBAs about the current state of the system, as well as the new demands being placed on it from the continuous feature development of the agile processes. Changing requirements are all part of the agile world, and are part of the power of this type of development, and additional features pose less of a problem than feature modifications, but the focus of short iterative steps can easily lead to a loss of focus on the greater need of the ability of the database and the datamodel itself to support the changing application.

In conclusion, for our agile data development processes to succeed, we need to use the skills where they are best suited. Database abstraction layers need to be tested by the database specialists, not in isolation, but within the application context itself, and any fundamental design decisions should be made by the people who understand the systems involved, at all levels.

Innodb et « autoshrink »

Lundi 18 juin 2007

Aujourd’hui j’ai reçu un message d’un collègue qui était surpris de voir que son « datafile » InnoDB gardait la même taille aprés avoir effacé des tables ou des éléments de ses tables.
C’est tout à fait normal! Toutes les bases de données marchent de la même facon. Un tablespace s’agrandira tout seul si vous le créez en mode autoextend et ce sous MySQL mais aussi Oracle, IBM DB2,… Si vous n’activez pas la fonction autoextend quand la base voudra allouer de la place, vous verrez une belle erreur.

La question est pourquoi? Performances!

Pour gagner en performances, vous voulez que votre base pré alloue de l’espace disque, des blocks de data pour vous. Nous parlons alors d’extend. Vu ces conditions veut on vraiment désallouer des extends pour les réallouer ensuite? La réponse est non!

Comment alors récupérer de l’espace? La seule solution est d’exporter les data, d’effacer les files et importer le tout.

Que peut on faire pour optimiser ça?

Effacer un maximum avant d’ajouter de l’information et ainsi contrôler du mieux que l’on peut la taille de votre tablespace.

Et pour MySQL?

Après avoir discuté avec Peter Zaitsev et Heikki Tuuri, il semblerait que « innodb_file_per_table » qui est apparu avec MySQL 4.1.3, pourrait contourner le problème. Cela semblerai être plus performant qu’un seul tablespace.

« innodb_file_per_table » est un paramètre de configuration dans le my.cnf, et est pris en compte seulement lors de la création d’une table. Donc pour migrer d’un seul tablespace vers plusieurs fichiers vous devrez encore une fois faire un export/import.

Une fois ceci fait, si vous effacez vos entrées et faite un « OPTIMIZE TABLE » l’OS libérera l’espace. Chaque table a son propre fichier .ibd et la commande recrée un fichier, efface l’ancien et renomme le nouveau.

Ce qui veut dire qu’a un instant t vous avez 2 fois les data, prévoyez donc une place suffisante sur votre disque et n’attendez pas le dernier moment.

Pour conclure, autoextend c’est bien mais vous devez néanmoins surveillez ça de prés.

Migration

Mercredi 11 avril 2007

Dans ma todo list de cette année, je dois m’occuper de la migration de bases de données IBM DB2 vers Oracle. Je n’entrerai pas dans la polémique sur le meilleur SGBD. Pour moi tout dépend de votre budget, de vos data mais aussi du niveau de compétence disponible dans votre équipe.
Je vais devoir regarder un peu plus en détail l’outil fourni par Oracle, je veux bien évidemment parler de Oracle Migration Workbench

Cet outil est sensé me simplifier la vie pour migrer des bases Sybase, Informix et DB2 vers de l’Oracle. (Oracle9i et Oracle10g). Il s’occupe du schéma, des triggers, des procédures stockées. Serait ce l’outil magique? Bon il n’est pas encore capable de modifier votre application client si vous utiliser du SQL spécifique à votre SGDB mais qui sait. :)

Premier bémol, il ne semble supporter que du DB2 sous Windows. En 8 ans de carrière je n’ai encore jamais joué avec des serveurs DB2 sous Windows, de l’AIX du Linux oui. Pour moi Windows s’arrête avec MSSQL serveur. La suite de cet aventure pour les mois à venir.