web-dev-qa-db-fra.com

Gestion d'une base de données SQL Server avec plus d'un téraoctet de données

Récemment, nous avons une base de données d'audit qui a dépassé un téraoctet et, comme nous avons des problèmes de stockage, la direction recherche des options.

Ma proposition est à la fin de chaque année, nous prenons une sauvegarde et tronquons toutes les tables qui garderont la base de données gérable.

Il ne sera pas avantageux d'avoir une base de données d'archives car elle consommera à nouveau le même espace.

Je voudrais avoir un avis d'expert sur les options que je peux proposer à la direction qui soit allouer plus d'espace ou tronquer toute la base de données chaque année.

sql-serversql-server-2014archivevldb
6
SQL_NoExpert
  1. Obtenez plus d'espace. Si vous avez besoin d'une entreprise de conserver autant de données, ils doivent trouver l'argent.
  2. Activez la compression de page pour les plus grandes tables (et index) (test test test!), Les données de journal se compressent extrêmement bien, mais la compression de cette quantité de données va prendre un certain temps.
  3. Voir point 1
8
Trubs

J'ajoute à Trubs 'réponse ci-dessus , que vous devriez voter positivement car il est sur la bonne voie, mais j'ajoute également plus d'options ici:

  1. Ajoutez plus d'espace (comme indiqué ci-dessus)
  2. Si vous disposez d'une grande quantité d'espace libre moyen par page sur les index, vous devez exécuter un ALTER INDEXREORG ¹ (si vous aviez suffisamment d'espace libre, je vous suggère plutôt une opération REBUILD , mais puisque nous parlons de manquer d'espace, cette opération peut ne pas se terminer sur des tables plus grandes). Pour trouver votre espace libre moyen par page, vous devez exécuter sys.dm_db_index_physical_stats dmv en utilisant le mode SAMPLED ou DETAILED ce qui prendra un certain temps.
  3. Purgez certaines données. Vous pouvez regrouper vos suppressions pour aider à réduire la journalisation et le verrouillage excessifs, ou la meilleure solution à long terme serait d'utiliser partitionnement de table et d'index ² et switch/tronquer la dernière partition pour une purge plus rapide des données.
  4. Activer la compression de page ou de ligne ² (comme indiqué ci-dessus). Vous pouvez voir les économies d'espace estimées en utilisant le sp_estimate_data_compression_savings procédure stockée.
  5. Après avoir mis à niveau vers SQL 2016 ou version ultérieure, vous pouvez convertir vos tables pour utiliser Clustered Columnstore Indexes ². Celles-ci vous donneront probablement les meilleurs taux de compression disponibles et amélioreront également les temps d'exécution des requêtes par rapport à ces tables. À noter, je ne vous suggérerais PAS de le faire en utilisant SQL 2014 (ou SQL 2012) car je considérerais que cette fonctionnalité est en version bêta jusqu'à SQL 2016 où elle a finalement été publiée avec les fonctionnalités appropriées.
  6. Utilisez Azure Stretch Database qui est une solution hybride qui vous permet de stocker des données qui ne sont pas souvent accessibles dans le cloud. Cela coûtera de l'argent et nécessitera au moins SQL 2016 pour l'utiliser, mais comme nous parlons de fonctionnalités dans les éditions futures, je pense qu'il devrait également être répertorié.

¹ - Disponible en édition Enterprise UNIQUEMENT

² - Disponible dans toutes les éditions de SQL Server à partir de SQL Server 2016 SP1. Il s'agit d'une fonctionnalité réservée aux entreprises avant ce Service Pack.

5
John Eisbrener