Le blog de SQLpro » volumétrie

Métriques du stockage de vos bases

SQLpro — Sun, 04 Oct 2015 10:19:41 +0000

Il est important pour un DBA de vérifier régulièrement le stockage de ses bases et anticiper sur les volumes afin de ne jamais avoir d’opérations de croissance qui pénalise fortement les performances (capacity planning). Pour cela il est nécessaire de vérifier régulièrement l’adéquation des « enveloppes » du stockage et du volume qui y figure afin de réagir avant qu’une croissance automatique ait lieu.

Pour ce faire vous devez mesurer régulièrement les volumes des fichiers, des données (tables et index) des transactions et réajuster les tailles de fichiers.
Voici une procédure qui vous donne ces métriques.

LA PROCÉDURE :

USE master;
GO

CREATE PROCEDURE dbo.sp__METRIQUE_STOCKAGE @REAJUSTE BIT = 0
AS
SET NOCOUNT ON;

IF @REAJUSTE = 1
--> réajustement des statistiques des espaces de stockage
DBCC UPDATEUSAGE (0);

--> volume des transactions
DECLARE @T TABLE (database_name sysname, log_size_mb FLOAT, log_space_used_percent FLOAT, STATUS bit);
DECLARE @TRANSACTIONS_RESERVEES_MO BIGINT,
@TRANSACTIONS_UTILISEES_MO BIGINT,
@TRANSACTIONS_UTILISEES_POURCENT DECIMAL(5,2);
INSERT INTO @T
EXEC ('DBCC SQLPERF(LOGSPACE)')
SELECT @TRANSACTIONS_RESERVEES_MO = ROUND(log_size_mb, 0),
@TRANSACTIONS_UTILISEES_MO = ROUND(log_size_mb * log_space_used_percent / 100.0, 0),
@TRANSACTIONS_UTILISEES_POURCENT = CAST(log_space_used_percent AS DECIMAL(5,2))
FROM @T WHERE database_name = DB_NAME();

-- taille de l'enveloppe de stockage :
WITH
T_FILES AS (
SELECT CAST(ROUND(SUM(CASE WHEN "type" = 1
THEN SIZE
ELSE 0
END) / 128.0, 0) AS BIGINT) AS TRANSACTIONS_RESERVEES_MO,
CAST(ROUND(SUM(CASE WHEN "type" != 1
THEN SIZE
ELSE 0
END) / 128.0, 0) AS BIGINT) AS DONNEES_RESERVE_MO
FROM sys.database_files),
T_DB AS (
SELECT TRANSACTIONS_RESERVEES_MO + DONNEES_RESERVE_MO AS BASE_TAILLE_MO,
DONNEES_RESERVE_MO, TRANSACTIONS_RESERVEES_MO
FROM T_FILES),
T_PAGES AS (
-- taille des pages données et index
SELECT CAST(ROUND(SUM(au.used_pages) / 128.0, 0) AS BIGINT) AS DONNEES_UTILISEES_MO,
CAST(ROUND(SUM(CASE
WHEN it.internal_type IN (202, 204, 211, 212, 213, 214, 215, 216)
THEN 0
WHEN au.TYPE != 1
THEN au.used_pages
WHEN p.index_id < 2
THEN au.data_pages
ELSE 0
END) / 128.0, 0) AS BIGINT) AS TABLES_MO
FROM sys.partitions AS p
INNER JOIN sys.allocation_units au
ON p.partition_id = au.container_id
LEFT OUTER JOIN sys.internal_tables AS it
ON p.object_id = it.object_id)
SELECT BASE_TAILLE_MO,
DONNEES_RESERVE_MO,
DONNEES_UTILISEES_MO,
CAST(100.0 * CAST( DONNEES_UTILISEES_MO AS FLOAT)
/ DONNEES_RESERVE_MO AS DECIMAL(5,2)) AS DONNEES_UTILISEES_POURCENT,
TABLES_MO,
DONNEES_UTILISEES_MO - TABLES_MO AS INDEX_MO,
CAST(100.0 * CAST( TABLES_MO AS FLOAT)
/ DONNEES_UTILISEES_MO AS DECIMAL(5,2)) AS TABLES_POURCENT ,
CAST(100.0 * CAST( DONNEES_UTILISEES_MO - TABLES_MO AS FLOAT)
/ DONNEES_UTILISEES_MO AS DECIMAL(5,2)) AS INDEX_POURCENT,
TRANSACTIONS_RESERVEES_MO,
@TRANSACTIONS_UTILISEES_MO AS TRANSACTIONS_UTILISEES_MO,
@TRANSACTIONS_UTILISEES_POURCENT AS TRANSACTIONS_UTILISEES_POURCENT
FROM T_PAGES CROSS JOIN T_DB;
GO

Pour pouvoir l'exécuter de n'importe quelle base, nous pouvons la marquer comme procédure système :

EXEC sp_MS_marksystemobject 'sp__METRIQUE_STOCKAGE';
GO

Les métriques fournies par cette procédure sont les suivantes :
BASE_TAILLE_MO : taille globale de la base y compris transactions
DONNEES_RESERVE_MO : taille réservée pour les données de la base
DONNEES_UTILISEES_MO : volume effectif des données de la base (tables et index)
DONNEES_UTILISEES_POURCENT : taux de remplissage des données dans les fichiers de la base
TABLES_MO : volume des données des tables (à titre indicatif)
INDEX_MO : volume des index (à titre indicatif)
TABLES_POURCENT : proportion du volume des tables en % (à titre indicatif)
INDEX_POURCENT : proportion du volume des index en % (à titre indicatif)
TRANSACTIONS_RESERVEES_MO : taille réservée pour le journal de transaction de la base
TRANSACTIONS_UTILISEES_MO : volume effectif des transactions de la base
TRANSACTIONS_UTILISEES_POURCENT : taux de remplissage des transactions dans les fichiers de la base

Les deux métriques les plus importantes sont indiquées en gras. C’est sur celles-ci qu’il faut réagir au plus vite en redimensionnant les fichiers ou en rajoutant de nouveaux fichiers…
Il est d’usage de se poser des questions lorsque les taux de remplissage dépasse 70%, de planifier la croissance à 80 et d’agir impérativement à 90%.

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.

Développez et administrez pour la performance avec SQL Server 2014

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Les plus grosses bases de données MS SQL Server actuelles sont en pétaoctets…

SQLpro — Mon, 04 Mar 2013 15:29:14 +0000

Régulièrement on me dit que MS SQL Server est un jouet comparé à Oracle ou TerraData.
Pourtant mon activité professionnelle m’a conduit à conseiller des clients ayant plusieurs téraoctets de données tant dans des bases relationnelles que décisionnelles.
Je me suis donc demandé quelles était les plus grosses bases de données hébergées par des serveurs Microsoft Windows / SQL Server…

Dépassant le To, on parle de VLDB (Very Large DataBase), mais en Po que doit-on dire ?

1) Pann Starrs – Recherche spatiale

Pann Starrs est l’acronyme de Panoramic Survey Telescope and Rapid Response System.
Système de relevé astronomique qui effectue de l’astrométrie et de la photométrie (résolution 1.4-gigapixel) d’une grande partie du ciel quasiment en continu. En détectant toute différence par rapport aux observations précédentes des

mêmes zones du ciel, Pann STARRS découvre un très grand nombre de nouveaux astéroïdes, comètes, étoiles variables et autre objets célestes (350 milliards de nouveaux objets découverts fin 2011). Sa mission principale est de détecter les objets géocroiseurs qui pourraient provoquer des impacts cosmiques. Sa base de données comprend tous les objets visibles depuis Hawaï (les trois quarts du ciel) jusqu’à une magnitude apparente de 24.

Taille de la base : Plusieurs Po (plus de 1 Po par an) de données célestes. Catalogue astronomique de 100 To environ.
Machines : 12 noeuds SQL Server 2008.

2) Myspace.com

Un des réseaux sociaux les plus visités au monde. 25% des américains y adhère. 280 millions d’utilisateurs dans le monde.

Taille de la base : > 1 Po
Nombre de serveurs SQL : 450
Travaux : 18 000 messages traités par seconde par serveur.
Infrastructure : 9 000 serveurs Web + 1 000 serveurs de cache (Windows et .net)

MySpace.com était au 5e rang mondial des sites web les plus visités du monde en 2008 en nombre d’utilisateurs unique. Le classement était le suivant (tous sites confondus) :
1 Google 145 243
2 Yahoo 139 181
3 Microsoft 128 255
4 AOL LLC 108 917
5 MySpace 85 119 (dont MySpace)

3) CENTIPEDE – Informatique

Centipede est le nom de code d’un projet d’un systèmpe opérationnel de traitement de très gros volumes de données et fournit à titre d’ISV.
Il est utilisé par plusieurs clients dont la plupart dépassent 100 To de données.

Taille de la base : plus de 500 To (plus grosse base cliente) sur 9 noeuds
Technologie : un serveur SQL « master node » (métadonnées), des serveurs esclave « data nodes ». Vues partitionnées ditsribuées (Distributed Partitioned Views) partitionnement d’index et de données(Data and Index Partitioning) Réplication transactionnelles (Transactional Replication) et cluster de secours (Failover Clustering). La charge de travail est répartie sur les différents nœuds. Des requêtes concurrentes peuvent être envoyées sur le même nœud ou sur des nœuds distribués.

NOTA : le but est la transparence des données. Ajout, suppression remplacement des nœuds facile et rapide. Rapidité de chargement et de migration des données des nœuds (plusieurs To en moins d’une journée). Les machines sont standardisées (la plupart du temps 16 cœurs et 64 Go de RAM).

4) Hotmail – courrier électronique

Dimensions du système : 1,3 milliards de boîtes aux lettres, données : 155 Po, grossissement : 2 Po par mois

Taille des bases SQL : 500 To
Nombre de serveurs SQL : 16 000 sur 160 clusters
Caractéristiques des machines SQL : 2 Xeon CPUs avec 4Go de RAM jusqu’à 2 quad-core Xeon CPUs avec 16Go RAM
Haute disponibilité : mirroring des bases de données.

5) Itaù – banque

Itaù est l’une des 15 plus grandes banque du monde (Brasil’S Banco Itaù) et héberge une base de données de gestion des risques de trésorerie chargée de calculer les position journalières et calculer les scores des risques de plus de 4,5 millions de transactions financières en portefeuille. Les évaluations de risque utilise SQL CLR (des calculs effectués en .net sous la responsabilité du serveur SQL) et concernent 4 milliards de calculs effectués chaque jour (environ 500 par transactions) sur une machine à 64 processeurs au rythme de 3 000 transactions financières par seconde…

Taille de la base : 50 To
BI : 180 millions de faits nouveau chaque jour

NOTA : le système a été migré d’Oracle pour lequel il prenait plus de 24 heures de traitement pour procéder au calcul journalier des risques. Il ne prends plus aujourd’hui que 1 heure, malgré l’absorption de la banque Unibanco par Itaù.

6) Webtrends – Analyse de trafic de site web

Taille de la base : données relationnelles 50 To, décisionnelles : 5 To

7) VimpleCom – Télécommunication (Russie)

bases de données des analyses de risque et traque de fraude des communications. Grossit chaque jour de 500 Go. Rétention de 40 jours dans la base.

Taille de la base : 20 To

8) First American – Assurance

L’un des plus grosse compagnie américaine d’assurance. Le système visé concentre les données des 50 entreprises du groupe dans une solution appelée First American Software Technology (FAST) développée sous plateforme Winows avec SQL

Server. L’entreprise génère 10 000 documents par jours et le système joue les intermédiaires entre les différentes applications informatiques.
Taille de la base : 8 To (la plus grosse, d’autres bases existent)
Nombre d’utilisateurs : 15 000
Utilisateurs concurrents : 7 000 en pointe
Nombre de batch : 15 000 par seconde en moyenne.

9) BWIN – jeux en ligne

Bwin est la plus grande compagnie de paris en ligne en Europe avec plus d’un million de paris par jour.

Taille de la base : plus de 4 To
Nombre de transactions : 30 000 par seconde en pic
haute disponibilité : 99,997% du temps (mesuré en réel)
Technologie : mirroring synchrone des serveurs entre deux datacenter éloignés de 12 miles

NOTA : Bwin est sponsor des clubs de football AC Milan et Real Madrid et figure dans le tube « poker face » de Lady gaga…

10) Gmarket – Boutique en ligne

Une des boutiques en ligne les plus prisée en Corée du sud. 12 millions de clients dont 3 millions réguliers. Près de 2 milliards de requêtes par jour. CA de 2 milliards de dollar par an.

Machine : HP Superdome doté de 64 processors et 512 Go de RAM
Transactions : 20 000 batch par seconde, pointes régulières à 23 000.

Quelques autres sociétés connues pour leurs VLDB :

En france :

Fnac.com
CDiscount
Vente privée

Dans le monde :

Hilton
Mediterranean Shipping Company (MSC)
Progressive (Assurances USA)
QR Limited (chemin de fer Australie / ERP SAP)
United Airlines (264 Go en 2010 en BI. Prévue pour 1,5 To)

Il en existe bien d’autres. mais la plupart ne veulent pas communiquer de chiffre.

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