Définition du problème
Nos utilisateurs doivent pouvoir interroger une base de données pour la plupart à jour. Les données peuvent être périmées jusqu'à 24 heures, ce qui est acceptable. Quelle serait l'approche la moins coûteuse pour obtenir et maintenir à jour une deuxième base de données avec une copie de production? Y a-t-il une approche à laquelle je ne pense pas?
Charge de travail
Nous avons une application tierce que nous utilisons pour surveiller l'activité de négociation d'actions. Pendant la journée, beaucoup de petits changements se produisent dans le cadre de divers flux de travail (oui, ce métier était valide. Non, c'est suspect, etc.). La nuit, nous effectuons de grandes opérations basées sur des ensembles (charge les transactions de la veille).
La solution et le problème actuels
Nous utilisons des instantanés de base de données . À 22 h, nous déposons et recréons l'instantané. Le traitement ETL commence alors. Ceci est évidemment éprouvant pour notre disque mais permet à nos utilisateurs de pouvoir interroger la base de données sans verrouiller la base de données (ils utilisent un frontal d'accès). Ils l'utilisent tard dans la nuit et tôt le matin pour remarquer des temps d'arrêt.
Le problème avec cette approche est double. La première est que dans le cas où le traitement nocturne échoue, et ce n'est pas très rare, nous arrivons à restaurer la base de données, ce qui entraîne la suppression de l'instantané. L'autre problème est que nos délais de traitement dépassent notre SLA. Nous essayons de résoudre ce problème en travaillant avec le fournisseur après avoir identifié des requêtes mal écrites et un manque d'indexation. L'instantané de la base de données est également à l'origine de ce ralentissement, comme en témoigne la différence de vitesse lorsqu'elle est présente et non --- choquante, je sais.
Approches envisagées
Regroupement
Nous avions activé le clustering de bases de données, mais cela ne répondait pas aux besoins de mise à disposition des données et compliquait généralement la vie de l'administrateur. Il a depuis été désactivé.
Réplication SQL Server
Nous avons commencé à étudier la réplication la semaine dernière. Notre théorie est que nous pouvons obtenir un deuxième catalogue debout et synchronisé avec la base de données de production. Avant le début d'ETL, nous couperons la connexion et la réactiverons uniquement une fois le processus ETL terminé.
L'administrateur a commencé avec la réplication de cliché, mais il craint que cela prenne plusieurs jours d'utilisation élevée du processeur pour générer le cliché ainsi que la consommation de disque requise. Il indique qu'il semble écrire toutes les données dans des fichiers physiques avant de les envoyer à l'abonné, de sorte que notre base de données de 0,6 To coûtera 1,8 To en frais de stockage. De plus, si cela prend plusieurs jours pour générer un snap, il ne rentrera pas dans le SLA souhaité.
Après avoir lu le bon article, il semble que Snapshot pourrait être le moyen d'initialiser les abonnés, mais nous voudrions ensuite passer à la réplication transactionnelle pour le garder synchronisé après cela. Je suppose que l'activation / la désactivation de la réplication transactionnelle ne forcera pas une réinitialisation complète? Sinon, nous ferons sauter notre fenêtre temporelle
Mise en miroir de bases de données
Notre base de données est en mode de récupération complète, donc la mise en miroir de bases de données est une option, mais j'en sais encore moins à ce sujet que la réplication. J'ai trouvé la réponse SO qui indiquait que "la mise en miroir de bases de données empêche l'accès direct aux données, les données en miroir sont uniquement accessibles via un instantané de base de données."
Expédition des journaux
Il semble que l' envoi de journaux pourrait également être une option, mais c'est une autre de ces choses que je ne connais pas. Serait-ce une solution moins coûteuse (mise en œuvre et maintenance) qu'autre chose? Basé sur le commentaire de Remus "L'envoi de journaux permet un accès en lecture seule à la copie de réplique, mais déconnectera tous les utilisateurs lors de l'application du prochain journal de sauvegarde reçu (par exemple toutes les 15-30 minutes)." Je ne sais pas combien de temps ce temps d'arrêt se traduirait, ce qui pourrait inquiéter les utilisateurs.
MS Sync
Je n'ai entendu parler de l'utilisation de Sync que le week-end dernier et je ne l'ai pas encore étudié. Je détesterais introduire une nouvelle technologie pour quelque chose avec une grande visibilité comme ce problème, mais si c'est la meilleure approche, tant pis.
SSIS
Nous faisons beaucoup de SSIS ici, donc générer quelques centaines de packages SSIS pour garder le secondaire synchronisé est une option pour nous, bien que laide . Je ne suis pas fan de cela, car cela représente beaucoup de frais de maintenance, je préfère que mon équipe ne s'en charge pas.
Instantané "magique" du SAN
Dans le passé, j'ai entendu dire que nos administrateurs utilisaient une technologie SAN pour effectuer des sauvegardes instantanées de disques entiers. Peut-être y a-t-il une magie EMC qui pourrait être utilisée pour faire des copies uberquick du mdf / ldf et nous pouvons ensuite détacher / attacher la base de données cible.
Sauvegarde et restauration
Je pense que nous prenons des sauvegardes complètes une fois par semaine, des différentiels tous les soirs et des tlogs toutes les 15 minutes. Si les utilisateurs pouvaient vivre avec la panne de 3-4 heures pour la restauration complète, je suppose que cela pourrait être une approche.
Contraintes
Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, stockage SAN EMC avec des lecteurs mappés sur des fichiers vmdk, commvault gérant les sauvegardes et 0,6 To de données dans le catalogue source. Il s'agit d'une application tierce que nous hébergeons en interne. La modification de leur structure est généralement mal vue. Les utilisateurs ne peuvent pas aller sans interroger la base de données et refuser d'être contraints en identifiant de manière proactive les tables qu'ils contrôlent pour faire leur travail.
Nos DBA sont pour le moment purement contractuels. Les chronométreurs sont partis et nous ne les avons pas encore remplacés. Les administrateurs d'application ne connaissent pas bien les questions de SQL Server et nous avons une équipe d'administrateurs de stockage / VM qui pourraient aider / entraver cet effort. Les équipes de développement ne sont pas actuellement impliquées mais peuvent être enrôlées en fonction de l'approche. Une solution plus simple à mettre en œuvre et à maintenir serait donc préférable.
Moi, je suis du côté du développement de l'hosue donc je ne peux que proposer des approches et je n'ai pas eu à m'occuper du côté administratif des choses. Donc, sans temps en selle d'administrateur, j'hésite à dire qu'une approche serait supérieure à une autre - tout semble parfait selon les documents. Je suis tout à fait disposé à suivre toutes les directions que vous suggérez, car selon moi, cela ne fera que me rendre plus précieux en tant que professionnel DB. J'ai une brouette mais aucune cape d'holocauste disponible .
Questions connexes
/programming/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste
/programming/4303020/sync-databases-mirroring-replication-log-shipping
/programming/4303020/sync-databases-mirroring-replication-log-shipping
http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/
Modifications
Pour répondre aux questions de @ onpnt
Acceptation de la latence des données
Les utilisateurs affichent actuellement des données qui ont jusqu'à 24 heures de retard. Les données ne sont à jour qu'en 2200
La quantité de données change dans une minute, une heure et un jour donnés Je ne sais pas comment quantifier cela. Heures d'ouverture, peut-être des centaines de changements par heure. Traitement nocturne, millions de lignes par jour ouvrable
Connectivité au secondaire
Réseau interne, hôte virtuel séparé et stockage dédié
Lire les exigences sur l'instance secondaire
Le groupe Windows aura un accès en lecture au secondaire, toutes les tables
Mise à jour de l'instance secondaire
Il n'y a pas de définition précise d'une exigence de disponibilité. Les utilisateurs veulent qu'il soit toujours disponible, mais sont-ils prêts à payer pour cela, probablement pas autant. En réalité, je dirais que 23 heures de la journée suffiraient.
Modifications du schéma existant et de tous les objets
Modifications peu fréquentes, peut-être une fois par trimestre pour les objets de table. Peut-être une fois par mois pour les objets de code.
Sécurité
Aucun besoin de sécurité particulier. Les autorisations de production correspondraient aux autorisations de la copie. Bien que j'y pense, nous pourrions révoquer l'accès en lecture des utilisateurs à prod et ne leur permettre que de lire la copie ... Pas une exigence cependant.
@darin strait
Revenir à l'instantané pourrait être une option, mais je pense qu'il y avait une raison pour laquelle ils ne l'ont pas poursuivi. Je vérifierai avec l'administrateur
@cfradenburg
Mon hypothèse était que nous n'utiliserions qu'une seule de ces approches mais c'est un bon point que les restaurations briseraient les "autres" technologies de synchronisation. Ils étudient la possibilité d'utiliser la magie des instantanés EMC. Comme l'administrateur l'a décrit, ils prendraient un instantané à 1900 et migreraient l'image vers la zone du secondaire. Cela devrait se terminer d'ici 2200, puis ils effectueraient un détachement et un rattachement de la base de données secondaire.
Emballer
2012-10-29 Nous avons évalué la magie des instantanés EMC et certaines autres options de réplication, mais les administrateurs de bases de données ont décidé qu'ils pouvaient mieux comprendre la mise en miroir. A voté les réponses parce qu'elles ont toutes aidé et m'ont donné beaucoup d'options ainsi que des «devoirs» à enquêter.