Sources d'informations sur l'administration de grandes bases de données SQL Server?

Question

Dans le cadre de mon rôle dans l'entreprise que je suis, j'ai été obligé de devenir le DBA de notre base de données. Certaines de nos tables ont un nombre de lignes proche de 100 millions et beaucoup de choses que je sais faire SQL Server (comme les jointures) se décomposent simplement à ce niveau de données. Je suis parti avec quelques options

1) Sortir et trouver un administrateur de base de données avec l'expérience de l'administration de VLDBs. Cela va nous coûter très cher et se faire au détriment des autres travaux dont nous avons besoin. Je n'en suis pas un grand fan.

2) La plupart de nos données sont des données historiques que nous utilisons pour l'analyse. Je pourrais simplement créer une copie de notre schéma de base de données et commencer à zéro avec des données mettant en attente toute analyse de nos données actuelles jusqu'à ce que je trouve une bonne façon de résoudre le problème (c'est ma "meilleure" solution actuelle).

3) Renseignez-vous auprès de la communauté des développeurs pour voir si je peux en apprendre suffisamment sur les grandes bases de données pour nous permettre de passer à l'action jusqu'à ce que je puisse implémenter la solution n ° 1.

Toute aide que quelqu'un pourrait fournir, ou tout livre que vous pourriez recommander serait grandement appréciée.

Answer 1

Voici quelques pensées, mais aucun d'entre eux sont des solutions rapides:

1. Élaborer une stratégie d'archivage pour les données dans vos grandes tables. Créer des tables avec des formats similaires à la table transactionnelle existante et copier les données dans ces tableaux sur une base périodique. Si vous pouvez obtenir loin avec whacking les données sur le système tx, alors bien.

2. Mettre en place un entrepôt de données relationnelles pour stocker les grands ensembles de données, avec des schémas en étoile comprenant des tables de faits et dimensions. Pour une introduction à cette approche il n'y a pas de meilleur livre (IMHO) que Ralph Kimball Data Warehouse Toolkit.

3. Pour l'analyse, envisagez d'utiliser MS Analysis Services pour pré-agrégation de ces données pour rapide interrogation .

4. Bien sûr, vous pouvez également regarder votre stratégie d'indexation dans la base de données existante .Soyez prudent avec des changements que vous pourriez ajouter des index qui permettrait d'améliorer l'interrogation au coût de performance d'insertion et transactionnelle . Vous pouvez également rechercher partitioning dans SQL Server.

5. Ne vous sentez pas mal à faire venir un DBA sur une base contractuelle pour aider ...

Pour moi, le mieux serait de commencer à enquêter sur le mouvement de ces données de la transaction système si cela n'est pas nécessaire pour une utilisation quotidienne.

Bien sûr, vous devrez acquérir de nouvelles compétences pour traiter ces quantités de données. Quoi que vous décidiez de faire, faites d'abord une sauvegarde!

Une autre chose à faire est de vous assurer que votre E/S est correctement répartie sur autant de broches que possible. Vos fichiers de données, les fichiers journaux et les fichiers de données temp db du serveur sql doivent tous se trouver sur des lecteurs séparés avec un système de base de données de cette taille.

Answer 2

DBA valent leur pesant d'or, si vous pouvez en trouver un bon. Ils se spécialisent dans ce que vous décrivez. S'il s'agit d'un problème ponctuel, vous pouvez peut-être en sous-traiter un.

Je crois que Microsoft offre un service similaire. Vous pourriez vouloir demander.

Answer 3

Vous aurez besoin d'un DBA là-bas, au moins sur contrat pour améliorer les performances de la base de données.

L'association à une table d'enregistrement de 100 millions ne devrait pas mettre le sereur de base de données à genoux. Mes clients de l'entreprise le font plusieurs centaines (voire des milliers) de fois par minute sur notre système.