« … une requête était restée ouverte dans la mémoire tampon d’une des bases de données. Cette transaction ne s’étant pas refermée, la mémoire tampon a stocké des ­requêtes jusqu’à saturation, au lieu de basculer vers une base de données de secours. » Ce sont les termes de Stéphane Richard, concluant l’origine de la gigantesque panne survenue sur le réseau des téléphones mobiles d’orange le 6 juillet 2012…

C’est dans la base de données du HLR (Home Location Register – un des composant essentiel de toute infrastructure de téléphonie mobile) qui contient les données des utilisateurs abonnés au service que c’est produite la panne. Cette base de données contient le numéro de téléphone des abonnés, diverses données personnelles ainsi que l’identifiant du GSM et les services qu’ils ont souscrits. La base stocke également des informations de routage destinées à suivre la position de l’appelant. C’est dire si cette base est vitale pour le système et en cas de panne, il est impossible de continuer le service des données.
Normalement tout est prévu pour basculer sur un serveur de secours en cas de panne du serveur principal. Mais le fait que cette transaction durait et avait saturé les journaux ainsi que le cache ont empêché le basculement du système.
Mais quel était l’origine de cette panne ? Dans la nuit du 3 au 4 juillet, le code du HLR (New Generation- Human Location Register) avait été mis à jour par la société Alcatel-Lucent. Une erreur de programmation d’un des composant est à l’origine de cette transaction non refermée ! Le HLR d’orange est composé de neuf front ends, qui accueillent le trafic entrant et de cinq back ends, qui stockent la localisation. La panne s’est déclenchée dans l’un des back ends.

Une explication vidéo détaillé de la gestion de la crise est disponible sur : http://www.youtube.com/watch?v=OYMffae2N6c&feature=player_embedded

Au total, la panne aura durée plus de douze heures. Elle a affecté 30 millions d’utilisateurs dont 2 millions chez Virgin et 2 autres millions chez Free.

Rappelons qu’orange utilise massivement Oracle pour stocker la plupart de ses données figurant en base.

Il est amusant de savoir que dans tous les cours d’administration de Microsoft SQL Server, un exercice que nous faisons faire, pour démontrer le système d’alerte intégré de SQL Server (l’Agent SQL) est de faire remonter une alerte par mail en cas de saturation du journal de transaction et de déclencher une procédure pour purger le journal… Cela fait partie du « B » « A » « BA » du métier de DBA !
Malheureusement, j’ai eu mainte fois l’occasion de constater que la connaissance et l’expérience en matière de base de données diminuait au fil de temps… Incompétence des développeurs qui testent de moins en moins leur code et incompétence des DBA qui ne mettent pas en place les bonnes pratique de gestion des serveurs SQL…

Le site web sur le SQL et les SGBDR

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES

Expert  S.G.B.D  relationnelles   et   langage  S.Q.L

Moste  Valuable  Professionnal  Microsoft  SQL Server

Société SQLspot  :  modélisation, conseil, formation,

optimisation,  audit,  tuning,  administration  SGBDR

Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’ntreprise SQL Spot