Quelle est la meilleure façon de sauvegarder un grand entrepôt de données en temps réel?

Question

J'ai un entrepôt de données db2 ese 9.7 non-dpf utilisant la compression de données avec 20 To de données qui reçoit 100 millions de lignes par jour via des charges toutes les 10 minutes et reçoit un million par jour avec 50 000 importations par jour. De plus, il y a une petite quantité de données transactionnelles associées aux deux autres grands ensembles de données.

Actuellement, nous utilisons des sauvegardes au niveau de l'application - et nous nous appuyons sur le chargement de tables récapitulatives précédemment exportées ou sur le rechargement des 100 millions de lignes par jour en cas de récupération. Mais pour la petite quantité de transactions et les importations - je voudrais des sauvegardes en ligne. Toutefois, il semble que les sauvegardes en ligne propres à un espace de table nécessitent une sauvegarde hors ligne initiale. Et c'est le problème, même si je peux rediriger la sauvegarde hors ligne vers/dev/null, une sauvegarde hors ligne prendra environ 48 heures d'arrêt. Ce qui est inacceptable. Et peut être nécessaire à nouveau à un moment donné dans le futur. À un certain point, nous diviserons probablement ceci en plus de 8 partitions et cela aiderait à la fois à cela et à charger des index. Mais cela peut ne pas arriver pendant un certain temps, et il est difficile de justifier des tâches qui ne devraient pas être nécessaires en premier lieu. EDIT: La raison pour laquelle nous ne sommes pas allés initialement avec DPF, et pourquoi ce n'est pas un problème de conduite pour nos requêtes est que plus de 99% de nos requêtes touchent des tables récapitulatives, et les 1% qui doivent La table avec plus de 3 milliards de lignes par mois peut presque toujours tirer parti du partitionnement de table, du MDC et des index afin de ne scanner qu'une quantité beaucoup plus petite. Ce que cela signifie, c'est que les heuristiques traditionnelles concernant la quantité de données par CPU ne s'appliquent pas toujours.

Un moyen de contourner cette exigence de sauvegarde hors ligne? Des outils tiers qui peuvent m'aider? D'autres suggestions?

Answer 1

Malheureusement, il n'y a pas vraiment moyen de contourner ce problème - vous devez planifier votre récupération lorsque vous effectuez la conception physique de la base de données. L'utilisation de tablespaces séparées avec partitionnement de plage vous permet de sauvegarder uniquement les tablespaces avec de nouvelles données (en supposant que vous savez quels tablespaces changent ...)

Généralement, cela ferait partie du domaine de l'utilisation de miroirs fractionnés ou d'instantanés au niveau du disque. . Ceci, bien sûr, nécessite que votre sous-système de disque supporte cette fonctionnalité (à moins que vous n'utilisiez un logiciel comme Veritas Volume Manager), ET que vous ayez la capacité de l'activer. DB2 supporte entièrement cela, et c'est très utile. Je l'ai fait avec EMC Symmetrix et Clariion; mais il nécessite une brève "panne" où vous geler les E/S de base de données afin d'émettre les commandes du système d'exploitation pour gérer la rupture des miroirs. Dans la version 9.5, DB2 a ajouté une fonctionnalité appelée Advanced Copy Services (ACS), qui permet aux fournisseurs de stockage de s'intégrer dans la commande BACKUP DATABASE. IBM prend cela en charge avec certains de ses sous-systèmes de stockage, et NetApp a également ajouté un support pour cela très rapidement. Il est assez étonnant de dire "BACKUP DATABASE HUGEDB USE SNAPSHOT" et de le regarder prendre 10 secondes. Et puis "L'INSTANTANÉ D'USAGE HUGEDB DE BASE DE DONNÉES RESTORE PRIS AU timestamp".