Implément SQL Server Agent Jobs dans AlwaysOn Availability Groups

L’Agent SQL Server ne fait pas partie de l’AG en Faite Les groupes de disponibilité AlwaysOn synchronisent les bases de données qui font partie d’un groupe de disponibilité, mais tout autre objet qui ne fait pas partie de ces bases de données n’est pas synchronisé (c’est-à-dire les connexions, les serveurs liés, les opérateurs, etc.) et cela inclut les travaux de l’Agent SQL Server.

Pour accomplir ce mode de création de travail d’agent SQL, j’utilise cette fonction pour tester si une base de données participe à un AG est accessible en écriture. Si c’est le cas, passez au reste des étapes du travail de l’agent SQL. Si ce n’est pas le cas, stopper le job

-- fn_hadr_group_is_primary
USE master;
GO
IF OBJECT_ID('dbo.fn_hadr_group_is_primary', 'FN') IS NOT NULL
  DROP FUNCTION dbo.fn_hadr_group_is_primary;
GO
CREATE FUNCTION dbo.fn_hadr_group_is_primary (@AGName sysname)
RETURNS bit
AS
BEGIN;
  DECLARE @PrimaryReplica sysname; 

  SELECT
    @PrimaryReplica = hags.primary_replica
  FROM sys.dm_hadr_availability_group_states hags
  INNER JOIN sys.availability_groups ag ON ag.group_id = hags.group_id
  WHERE ag.name = @AGName;

  IF UPPER(@PrimaryReplica) =  UPPER(@@SERVERNAME)
    RETURN 1; -- primary

    RETURN 0; -- not primary
END; 

Utilisez la fonction fn_hadr_group_is_primary dans une nouvelle étape de travail pour déterminer si cette instance sql est un réplica principal. S’il ne s’agit pas d’un réplica principal, nous émettons une demande d’arrêt de la tâche tout en identifiant le nom de la tâche actuelle à l’aide des jetons de l’agent SQL Server.

-- Detect if this instance's role is a Primary Replica.
-- If this instance's role is NOT a Primary Replica stop the job so that it does not go on to the next job step
DECLARE @rc int; 
EXEC @rc = master.dbo.fn_hadr_group_is_primary N'my-ag';

IF @rc = 0
BEGIN;
    DECLARE @name sysname;
    SELECT  @name = (SELECT name FROM msdb.dbo.sysjobs WHERE job_id = CONVERT(uniqueidentifier, '$(ESCAPE_NONE(JOBID))'));
    
    EXEC msdb.dbo.sp_stop_job @job_name = @name;
    PRINT 'Stopped the job since this is not a Primary Replica';
END;

batch mode sql server in RowStore

Qu’est-ce qu’un batch mode ?

En termes simples, un batch est une structure de stockage interne de 64 Ko de large qui contient un groupe de lignes allant de 64 à 900 selon le nombre de colonnes qui les composent. Chaque colonne utilisée par la requête est stockée dans un vecteur de colonne continu d’éléments de taille fixe, où le vecteur de ligne qualificatif indique quelles lignes font encore logiquement partie du lot 

Pour commencer je vais exécuter exécutez mon code TSQL où nous gardons le niveau de compatibilité de la base de données à 140 qui représente SQL Server 2017 Vérifiez le plan d’exécution de la requête Remarquez bien que comment le mode d’exécution est ROW

CPU time = 142656 ms, elapsed time = 43660ms.

Maintenant, nous prenons la même base de données avec la même requête et on active le mode mode batch en définissant le niveau de compatibilité de la base de données sur « 150 »

Ici, nous voyons que, comme prévu, le stockage est « RowStore », mais le mode d’exécution réel est désormais « Batch ». Et les résultats reviennent en un peu moins de 1/3 du temps de la même requête sur la même table en mode ligne

CPU time = 142547 ms, elapsed time = 24702ms.

Pour obtenir le mode batch, il vous suffit d'exécuter vos requêtes avec le dernier niveau de compatibilité sur SQL Server 2019 en Edition entreprise sur des larges tables  

Erreur de groupe de disponibilité AlwaysOn SQL Server: 1408 La jointure de base de données sur le réplica secondaire entraînait une erreur

J’ai été en train de configurer un environnement SQL Server AlwaysOn à deux nœuds. Lors de la configuration, nous avons reçu  »
Error: 1408 Joining database on secondary replica resulted in an error.  » Comment cette erreur s’est-elle produite et comment la résolvons-nous?

Vous pouvez voir ici que SQL Server AlwaysOn a été configuré avec succès sur le réplica secondaire xxxx, alors qu’une erreur s’est produite pour le réplica secondaire xxxx. Nous allons maintenant vérifier les détails de l’erreur pour résoudre ce problème. Vous pouvez cliquer sur le lien « Erreur » pour obtenir les détails de l’erreur, comme indiqué dans la capture d’écran ci-dessous.

vous verrez que la base de données posant problème comporte un point d’exclamation. Faites un clic droit sur cette base de données et cliquez sur «Rejoindre un groupe de disponibilité»

Maintenant, si vous lancez le rapport de tableau de bord SQL Server AlwaysOn, vous pouvez voir l’état actuel de la configuration AlwaysOn, comme indiqué dans la capture d’écran ci-dessous.

Les détails de l’erreur indiquent que « la copie distante de la base de données » DRTest « n’est pas récupérée suffisamment pour permettre la mise en miroir de la base de données ou pour la joindre au groupe de disponibilité. Vous devez appliquer les enregistrements de journal manquants à la base de données distante en restaurant le fichier en cours. enregistrer les sauvegardes de la base de données principale / principale. (Microsoft SQL Server, Erreur: 1408) « . Cela signifie que les bases de données source et cible ne sont pas synchronisées. Nous allons résoudre ce problème dans cette astuce. Cliquez sur le bouton OK pour fermer cette fenêtre.

Alter database production SET HADR AVAILABILITY GROUP = AVGProduction;

Msg 1478, Level 16, State 101, Line 1
The mirror database, « XXXXX », has insufficient transaction log data to preserve the log backup chain of the principal database. This may happen if a log backup from the principal database has not been taken or has not been restored on the mirror database.

Vous devez restaurer la sauvegarde du journal qui a été prise à partir de la base de données primaire vers la base de données secondaire et réessayer. Si vous ne trouvez pas la sauvegarde du journal ou si vous avez effectué la sauvegarde avec une autre application de sauvegarde, effectuez une sauvegarde différentielle, puis effectuez une sauvegarde du journal à partir de la base de données principale et restaurez ces sauvegardes dans la base de données secondaire en mode Norecovery

 cliquez avec le bouton droit de la souris sur la base de données secondaire dans l’onglet Bases de données de disponibilité, puis cliquez sur « Join To Avaibility Groupe »

. Au bout d’un moment, vous constaterez que l’état de la base de données secondaire est à nouveau synchronisé et que le problème est corrigé.

on passe maintenant à la réplique principale xxxxxx et lancez le rapport de tableau de bord SQL Server AlwaysOn pour cette configuration. Le rapport de tableau de bord du groupe de disponibilité « xxxxx » apparaît dans le volet de droite. L’état du groupe de disponibilité est maintenant sain et toutes les valeurs d’état sont vertes. Vous pouvez valider la configuration de la réplique secondaire xxxxx ainsi que celle illustrée ci-dessous.

AlwaysOn Le réplica secondaire est à l’état » resolving state » après le basculement

bonjour

J’ai récemment installé un simple cluster de basculement à 2 nœuds qui sera utilisé pour le groupe de disponibilité AlwaysOn. Après l’installation, j’ai proposé au client d’effectuer des tests de basculement, non seulement pour connaître le comportement du cluster de basculement Windows, mais également pour voir comment les applications réagiraient en cas de basculement. 
Lorsque j’ai désactivé la carte réseau sur le nœud hébergeant le groupe de clusters, le basculement a bien fonctionné comme prévu

J’ai réactivé la carte réseau et effectué le même test sur l’autre nœud (qui hébergeait maintenant le groupe de clusters). À ma grande surprise, il n’y a pas eu de basculement, mais le nom du cluster et l’adresse IP ont simplement été déconnectés

Cependant J’ai essayer 3  fois de basculé le secondaire il reste Toujours dans un état de « Résolution ».

J’ai vérifié les événements du cluster et constaté l’erreur suivante: « Le rôle de cluster ‘Groupe de cluster’ a dépassé son seuil de basculement»

Message D’erreur :
Based on the failure policies for the resource and role, the cluster service may try to bring the resource online on this node or move the group to another node of the cluster and then restart it. Check the resource and group state using Failover Cluster Manager or the Get-ClusterResource Windows PowerShell cmdlet.

selon la configuration du cluster par défaut La limite maximale de basculement est définie sur 1 fois sur 6 heures.

Par défaut, l’unité de temps est de 6h et le nombre de fois est de n-1 (n étant le nombre de nœuds). Par exemple avec une architecture à 2 nœuds, vous pouvez basculer au plus 4 fois dans la même journée (24 heures) , à condition que ces quatre basculement aient lieu à plus de 6h d’intervalle

vous devez cliquer avec le bouton droit sur le nom du cluster et sélectionner les propriétés. Maintenant, si vous regardez de plus près, il existe un «lien» dans les premières fenêtres appelé «Gérer le groupe de ressources du cluster principal». 
Je n’ai pas remarqué ce lien car la plupart des liens ne servent qu’à ouvrir les fichiers d’aide…

Accédez à l’onglet Basculement, où vous trouverez le nombre maximal d’échecs dans la période spécifiée. Par défaut, il est défini sur 1 dans une période de 6 heures. Cela ne suffit pas lors des tests de cluster de basculement et vous indiquera le problème que j’ai rencontré qui a échoué / hors connexion. 
Remplacez-le par une valeur plus élevée, telle que 10 par exemple

Veuillez noter que j’ai utilisé ces configurations uniquement à des opération de test

N’oubliez pas de rétablir la valeur par défaut une fois vos tests terminés.

Comment Activé la clé de licence SQL Server?

bonjour a tous

Ce tutoriel explique comment réaliser un upgrade SQL Server Evaluation Edition valable sur une période de 180j  vers une édition payante Entreprise

La procédure de mise à jour de la clé de produit SQL server est simple. En réalité, ces étapes sont identiques à celles requises pour mettre à niveau l’édition de SQL Server

Si SQL est déjà installé, vous pouvez également lancer le «Centre d’installation» en cliquant sur Démarrer-> Programmes -> Microsoft SQL Server 2017> Outils de configuration-> Centre d’installation SQL Server [(64 bits)]

donc Vous obtiendrez l’écran ci-dessous  Allez à « Maintenance » et cliquez sur « Edition Upgrade » comme indiqué ci-dessous

Renseigner après la clé de produit (product key) pour sélectionner l’édition achetée.

Vérifier le récapitulatif des opération à effectuer, ici l’action est une « Edition Update » vers l’édition « Entreprise » avec la liste des fonctionnalités et le nom de l’instance conservée

un écran récapitule les étapes de migration avec leur état

Maintenant si on vérifie on voit  qu’on arrive bien a activé la version Entreprise Edition

Le serveur SQL est maintenant sous licence Entreprise et il est bien Activé

Si vous voulez le faire en ligne de commande, vous pouvez lancer setup.exe avec les paramètres requis.

Setup.exe /q /ACTION=EditionUpgrade /INSTANCENAME=MSSQLSERVER /PID=” /IACCEPTSQLSERVERLICENSETERMS

bonne Activation

TRUNCATE TABLE WITH PARTITIONS (SQL Server 2016)

Bonjour

TRUNCATE TABLE WITH PARTITIONS est une nouvelle Amélioration de T-SQL dans SQL Server 2016
Il est bien connu que TRUNCATE TABLE est plus rapide que l’instruction DELETE. TRUNCATE TABLE utilise des ressources système et un fichier journal transactionnel inférieurs à ceux d’une instruction DELETE.

À partir de SQL Server 2016, Microsoft a introduit une nouvelle clause TRUNCATE TABLE WITH PARTITIONS qui peut être utilisée pour tronquer toutes les lignes disponibles dans une partition

Passons en revue une simple démonstration pour nous montrer comment cela fonctionne. Nous allons commencer par ajouter un  nouveaux groupes de fichiers nommé FG1 et UN  fichiers de données à notre base de données AdventureworksDW2016CTP3 existante avec le script ci-dessous:

use [AdventureworksDW2016CTP3]

GO
use [master]

GO
USE [master]
GO
ALTER DATABASE [AdventureworksDW2016CTP3] ADD FILEGROUP [FG1]
GO

Une fois que le groupe de fichiers et les fichier ndf de base de données sont prêts, nous allons créer la fonction de partitionnement ainsi que le schéma de partitionnement

use [AdventureworksDW2016CTP3]

GO
use [model]

GO
USE [master]
GO
ALTER DATABASE [AdventureworksDW2016CTP3] ADD FILE ( NAME = N'AdventureWorksDW2014_Data2', FILENAME = N'C:\Data\AdventureWorksDW2016CTP3_Log.ndf' , SIZE = 8192KB , FILEGROWTH = 65536KB ) TO FILEGROUP [FG1]
GO

USE [AdventureworksDW2016CTP3]
GO
BEGIN TRANSACTION
CREATE PARTITION FUNCTION [Parttion1](datetime) AS RANGE LEFT FOR VALUES (N'2005-01-01T00:00:00', N'2005-05-01T00:00:00', N'2005-11-01T00:00:00', N'2007-01-01T00:00:00', N'2010-05-05T00:00:00', N'2015-05-05T00:00:00')

CREATE PARTITION SCHEME [Partition1] AS PARTITION [Parttion1] TO ([FG1], [FG1], [FG1], [FG1], [FG1], [FG1], [FG1])

ALTER TABLE [dbo].[FactResellerSalesXL_PageCompressed] DROP CONSTRAINT [PK_FactResellerSalesXL_PageCompressed_SalesOrderNumber_SalesOrderLineNumber] WITH ( ONLINE = OFF )

SET ANSI_PADDING ON

ALTER TABLE [dbo].[FactResellerSalesXL_PageCompressed] ADD  CONSTRAINT [PK_FactResellerSalesXL_PageCompressed_SalesOrderNumber_SalesOrderLineNumber] PRIMARY KEY NONCLUSTERED
(
	[SalesOrderNumber] ASC,
	[SalesOrderLineNumber] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, DATA_COMPRESSION = PAGE) ON [FG1]

CREATE CLUSTERED INDEX [ClusteredIndex_on_Partition1_636714223260918622] ON [dbo].[FactResellerSalesXL_PageCompressed]
(
	[ShipDate]
)WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, DATA_COMPRESSION = PAGE ON PARTITIONS (1 TO 7)) ON [Partition1]([ShipDate])

DROP INDEX [ClusteredIndex_on_Partition1_636714223260918622] ON [dbo].[FactResellerSalesXL_PageCompressed]

COMMIT TRANSACTION

Nous allons maintenant l’exécution de l’instruction truncate TABLE. L’instruction TRUNCATE ci-dessous est utilisée pour tronquer le deuxième et troisième partitions et la quatrième partition de la table FactResellerSalesXL_PageCompressed ce qui supprimera les données de ces partition

TRUNCATE TABLE FactResellerSalesXL_PageCompressed
WITH (PARTITIONS (2 TO 4));
GO

Maintenant interrogeons la table sys.partitions pour vérifier le nombre d’enregistrements dans chaque partition avant et après l’application de l’instruction TRUNCATE TABLE:

Activer le chiffrement transparent des données TDE

bonjour

Vous pouvez configurer le chiffrement de données transparent (TDE) lorsque vous créez une base de données pour la première fois ou que vous pouvez l’appliquer à une base de données existante. Dans ce dernier cas, une fois que TDE a été activé, il sera configuré pour chiffrer vos données existantes en arrière-plan.

Dans les deux cas, les étapes sont les mêmes. Nous allons les parcourir rapidement avant d’entrer dans les détails.

Vous devez d’abord avoir une clé principale de base de données (DMK) dans la base de données principale et un certificat qui sera utilisé par TDE

USE MASTER;

CREATE MASTER KEY
ENCRYPTION BY PASSWORD = 'MasterkeyTunisie20180819';

Puis vous devrez procéder a crée votre propre certificat

CREATE CERTIFICATE TDE_Cert
WITH SUBJECT = 'Chiffrement base de données ';

Cet certificat est essentiel pour pouvoir accéder aux données chiffrées par TDE, vous devez donc vous assurer de les sauvegarder

Pour sauvegarder votre certificat il faut procéder a faire :

BACKUP CERTIFICATE TDE_Cert
TO FILE = 'C:\TDE_Cert'
WITH PRIVATE KEY
(
    FILE = 'C:\Privatekey_cert',
    ENCRYPTION BY PASSWORD = 'Password_TDE@20180819'
);

Ensuite, dans la base de données chiffrée avec TDE, vous devez créer une clé de chiffrement de la base de données (DEK) et spécifier le certificat

USE Production ;

CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TDE_Cert  ;

Enfin, vous Pouvez activez le cryptage sur votre base de donné :

ALTER DATABASE TestTDE SET ENCRYPTION ON;

En mode Graphique

vous pouvez voir Si votre bases de données est activées par TDE en consultant la colonne is_encrypted:

SELECT name
FROM sys.databases
WHERE is_encrypted = 1;

ou a travers

SELECT
   d.name,
   k.encryption_state,
   k.encryptor_type,
   k.key_algorithm,
   k.key_length,
   k.percent_complete
FROM sys.dm_database_encryption_keys k
INNER JOIN sys.databases d
   ON k.database_id = d.database_id;

bonne chiffrement

Mise-en-place de la réplication Transactionnelle

Bonjour

Dans cet article, nous allons mettre en place la réplication sur SQL Server 2016 . La réplication consiste en un transfert des données d’un serveur vers un ou plusieurs autres serveurs SQL

De manière générale, la réplication nécessite trois éléments clefs (fonction du type de réplication  :

· Un serveur de publication : serveurs qui rendent leur donnée accessible à la réplication

· Un serveur de distribution : serveurs qui distribuent les données à répliquer

· Et des abonnées bien sûr : les serveurs de destinations des données répliquées.

1-Mise en œuvre du distributeur

SQL Server Management Studio propose différent assistant graphiques pour mettre en place, surveiller et paramétrer l’environnement de réplication

Tous ces éléments sont accessibles depuis le nœud Réplication de l’explorateur d’objets de SQlSMO

La mise en place d’un distributeur demande des privilèges d’administrateur c’est-à-dire être membre de sysadmin

*sélectionner le choix Configurer la distribution dans le menu contextuel associé au nœud Réplication

L’assistant suivant permet de création d’une publication est alors exécuté et cet assistant permet de sélectionner / configurer un distributeur pour la réplication                                                                             Cet assistant va tout d’abord demander de préciser le serveur qui va jouer le rôle de distributeur

Il est alors possible de sélectionner le serveur qui hébergera également la publication (éditeur/distributeur) ou bien de sélectionner un distributeur distant

A l’étape suivante, l’assistant permet de spécifier le dossier utilisé pour les fichiers de capture instantanés. Un dossier local est proposé par défaut  Si la réplication doit être accessible depuis le réseau, il est nécessaire de préciser un nom de chemin réseau

Puis L’assistant permet de préciser le nom de la base de distribution ainsi que l’emplacement Physique du fichier de donnée et du journal  Comme le montre l’écran ci-dessous la base se nomme par défaut distribution et les dossiers proposés sont ceux spécifiés par défaut

Enfin, l’assistant offre la possibilité de réaliser le paramétrage immédiatement avec une fenêtre qui montre la bonne configuration

Enfin, l’assistant offre la possibilité de réaliser le paramétrage immédiatement avec une fenêtre qui montre la bonne configuration

 

Le menu contextuel propose de visualiser la propriété du serveur de distribution elle permet aussi de désactiver la distribution                                                                        Toujours depuis l’explorateur d’objets, il est possible de visualiser la base de données système distribution qui a été créé à l’aide de l’assistant

2-Création de la publication

Au moment de la création d’une publication les éléments suivantes doivent être spécifiés lors de l’éxecution de l’assistant de création

*le Type de Réplication (capture instantané, Transactionelle ou fusion)

L’activation de la publication sur les bases est possible depuis la fenêtres présentant les propriétés du serveur de publication ,le Choix Propriétés du serveur de publication depuis le menu contextuel associé au nœud Réplication de l’explorateur d’objects permet d’afficher cette fenêtres

La création d’une publication est également réalisée par intermédiaire d’un assistant sous SQL SERVER  Management studio                                                                                     Pour crée une nouvelle publication il faut sélectionner Nouvelle Publication

La première étape de l’assistant consiste à sélectionner la base de données qui contient le ou les objets qui vont participer à la publication Cette boite de dialogue montre Toutes les bases de donnée utilisateurs qu’elles soient ou non activées pour la réplication      Dans l’exemple ci-dessous, seul la base Production est activée pour la réplication, alors que toutes les bases sont présentes dans la fenêtre

Dans l’étape ci-dessous la publication est définit dans la cadre d’une réplication transactionnelle, c’est-à-dire  que les données sont modifiées sur l’éditeur et que ces modifications sont reportés sur les abonnées par le processus de réplication

Après que le type de réplication est défini, il est possible de sélectionner les éléments de la base qui participent à cette publication, c’est-à-dire définir les articles                         Dans l’exemple ci-dessous, la publication va compter un seul article

Remarque : Seuls les tables qui possèdent une clé primaire peuvent participer à une publication                                                                                                                             Pour chaque article, il est intéressant d’afficher sa propriété afin de saisir une description pour chaque article et fixer le schéma et le nom de la table                              Les propriétés de l’article publié permettent de définir le composant a adoptée sur les index ,les valeurs par défaut  les autorisations

L’étape suivante permet de définir s’il est nécessaire ou non de réaliser une capture instantanée et éventuellement de planifier la création régulière de nouvelle capture instantanée                                                                                                                                          Ce dernier point est particulièrement intéressant lorsque le volume de données modifiées est important                                                                                                                    Par la suite l’assistant demande à spécifier les comptes de sécurité qui vont être utilisées par les agents de capture instantanée et de lecture du journal pour se connecter au serveur

Avant de cliquer sur Terminer pour crée la publication, l’assistant offre la possibilité de crée les scripts Transact SQL relatifs à la création de cette nouvelle publication                La dernière étape de l’assistant permet de nommer la publication puis de demander sa création

Après leur création, il est possible de visualiser et de modifier les publication depuis SQL Server Management Studio, il est possible par l’intermédiaire des propriétés de la publication de modifier les Choix définis lors de l’exécution de l’assistant de création de la publication

3-les abonnements                                                                                                                   S’abonner à une publication signifie que l’abonné accepte les données répliquées sur une base de destination                                                                                                                           SQL Server Management Studio propose un assistant pour crée de nouveau abonnement, il est possible de lancer cet assistant en sélectionnant l’option Nouveau Abonnement dans le menu contextuel attache soit depuis le nœud Réplication-Abonnement Locaux soit associé à une publication  C’est d’ailleurs cette dernière possibilité qui est illustrée par l’écran Ci-dessous

Ensuite l’assistant demande de préciser le type de l’abonnement c’est-à-dire si l’abonnement sera de type poussé(avec l’exécution de l’agent sur le distributeur) ou bien tiré (avec l’exécution de l’agent sur l(abonné) Dans cette exemple c’est un abonné de type poussée qui est selectioné                                                                                                        L’assistant permet ensuite de sélectionner l’abonné Si l’abonné n’apparait pas dans la liste proposée, Il faut utiliser le bouton Ajouter un abonné pour inscrire le serveur de ainsi avoir la possibilité de le Sélectionner en tant qu’abonnée lors de la sélection d’un serveur abonné il faut également spécifier La base de données destinatrice de l’abonnement

Ensuite, l’assistant demande de préciser les comptes de sécurité qui seront utilisés par l’agent de distribution pour se connecter au serveur de distribution et sur l’abonné

Par la suite, l’assistant demande de préciser le mode d’exécution de l’agent de distribution, Dans L’exemple présenté ci-dessous l’agent est exécuté en continue de façon à reporter le plus rapidement

Le même Type de question est posé par l’assistant pour l’exécution de la capture instantané qui peut Être exécuté soit immédiatement soit lors de la première synchronisation

Comme pour la création de la publication l’assistant donne la possibilité de générer les scripts Transact SQL Correspondants

Puis l’assistant présente un écran de synthèse avant de terminer la création de l’abonnement

 

Depuis SQL Server il est possible de visualiser l’ensemble des abonnements définis par rapport à une publication mais aussi l’abonnement souscrit localement par le serveur   Le moniteur de réplication peut être lancé depuis le distributeur pour suivre le déroulement et l’exécution des différentes agents de la réplication Ce moniteur est accessible en sélectionnant lancer le monitor de réplication depuis le menu contextuel associé au nœud Réplication de l’explorateur d’objets de SQL server Mangement Studio

Le menu contextuel associé à la publication permet également d’obtenir les comptes rendus d’exécution des agents de capture instantanée et de lecture du journal

4-supression de la réplication

La suppression d’an abonnement empêche les nouvelles mis à jour de la base de destination mais pour autant cette dernière n’est pas supprimée ni même nettoyée il reviendra à un administrateur du serveur de destination de supprimer le schéma crée par la mise en place de la publication

 

La désinstallation

Il est possible de désinstaller un distributeur par le biais de l’assistant Réplication Réplication , Désactiver l’assistant Publication et Distribution

Les effets sont les suivants :

-les bases de données distribution du serveur sont supprimées

– Toutes les éditeurs qui utilisent ces distributeurs sont désactivés et toutes les publications sont supprimées

– Toutes les abonnements sont supprimés, mais les données d’abonnement restent sur les abonnés

Bonne configuration de la réplication

Mise-en-place du log shipping

Bonjour

L’envoi de journaux ou le log shipping  est une technologie de base de SQL Server de haute disponibilité qui fait partie du SQL Server. Il s’agit d’un processus de sauvegarde et de restauration automatisé qui vous permet de créer une autre copie de votre base de données pour le basculement. L’envoi de journaux implique la copie d’une sauvegarde de base de données et de sauvegardes de journaux de transactions ultérieures à partir du serveur principal (source) et la restauration des sauvegardes de bases de données et de journaux de transactions sur un ou plusieurs serveurs secondaires (Stand By / Destination). La base de données cible est en mode veille ou non-récupération sur le (s) serveur (s) secondaire (s), ce qui permet de sauvegarder les journaux de transactions suivants sur le serveur principal et de les transférer (ou de les copier) sur les serveurs secondaires.

Pour débuter il faut s’assurez-vous que votre base de données est en  mode de récupération compléte ou journalisée en bloc. Vous pouvez modifier le modèle de récupération de base de données à l’aide de la requête ci-dessous. Vous pouvez vérifier le modèle de récupération de base de données en interrogeant sys.databases

USE master
GO
ALTER DATABASE Database_log SET RECOVERY FULL WITH NO_WAIT
GO

Avant de configurer l’envoi de journaux, vous devez créer un partage pour que les sauvegardes du journal des transactions soient disponibles sur le serveur secondaire. Il s’agit d’un partage du répertoire dans lequel les sauvegardes du journal des transactions seront générées

Important :Les comptes exécutant le service Agent SQL Server  doivent pouvoir avoir accès au dossier de partage

Etape1:

on va procéder tout d’abord a restaurer la base de donnée sur le second serveur soit en mode with Standby ou en mode NO Recovery 

En faite La base de données secondaire peut être dans deux modes différents: Mode veille with Standby  ou en mode en cours de récupération  NO Recovery 
Lorsque la base de données secondaire est en mode veille, les utilisateurs peuvent se connecter et émettre
des instructions de type SELECT  sur la base de données.

Lorsque la base de données secondaire est en cours de récupération NO Recovery 
les utilisateurs ne peuvent pas se connecter à la base de données. Dans les deux modes, vous pouvez restaurer les journaux de transactions
à la base de données secondaire. Vous ne pouvez pas restaurer les journaux de transactions lorsque les utilisateurs sont
connecté à la base de données

 Sur le serveur secondaire, vous pouvez vérifier l’état de la base secondaire restaurée en mode veille

Etape 2

Sur le serveur principal, faites un clic droit sur la base de données depuis  SSMS et sélectionnez Propriétés. Ensuite, sélectionnez la page d’expédition du journal des transactions. Cochez la case « Activer cela en tant que base de données primaire dans une configuration d’envoi de journaux »


L'étape suivante consiste à configurer et planifier une sauvegarde du journal des transactions. Cliquez sur Paramètres de sauvegarde ... pour ce faire

Configuration des paramètres de sauvegarde des journaux de transaction de la base principale (avec 3 jours de rétention)

Planifier le job du sauvegarde selon votre besoin ici chaque 15 minutes

Dans cette étape, nous allons configurer l’instance secondaire et la base de données. Cliquez sur le bouton Ajouter … pour configurer l’instance et la base de données du serveur secondaire. Vous pouvez ajouter plusieurs serveurs si vous souhaitez configurer un ou plusieurs journaux d’expédition de serveur

.

Après connexion à l’instance de la base secondaire, choix du mode d’initialisation de cette dernière :

.

Ici, vous devez spécifier les informations sur l’état de restauration de la base de données et le planification  du restauration. Cela va créer le travail de restauration sur le serveur secondaire.

Cliquez sur le bouton OK pour terminer la configuration de l’expédition du journal et il vous montrera l’écran ci-dessous.

Exécuter le travail de sauvegarde sur l’instance SQL principale et copier, restaurer les travaux dans l’instance secondaire. Créez les tâches et les alertes d’expédition des journaux, puis commencez l’envoi des journaux. Vérifiez que les sauvegardes vont dans le bon dossier, sont copiées de LS_Primary à LS_Secondary correctement, et sont restaurées dans SQL2

Cliquez avec le bouton droit sur Instance principale et secondaire, sélectionnez les rapports et cliquez sur l’état d’expédition du journal des transactions. Cela vous montrera l’état de la synchronisation de la livraison de la base de données entre deux instances

Pour supprimer l’envoi de journaux
Connectez-vous à l’instance de SQL Server qui est actuellement le serveur principal d’envoi de journaux et développez cette instance.

Développez Bases de données, cliquez avec le bouton droit sur la base de données principale d’envoi de journaux, puis cliquez sur Propriétés.

Sous Sélectionner une page, cliquez sur Expédition du journal des transactions.

Désactivez la case à cocher Activer cela en tant que base de données principale dans une boîte de dialogue de configuration de l’envoi de journaux.

Cliquez sur OK pour supprimer l’envoi de journaux de cette base de données primaire

Bonne configuration

Restauration de page à partir de SSMS

BONJOUR

Dans Cette rubrique on va expliquer comment restaurer des pages dans SQL Server POUR Réparer les pages Endommagée

Si vous été en mode de récupération complète SQL server vous permet de restaurer uniquement une ou plusieurs pages sans vous été  obliger de restaurer toute la Totalité du base de données.

Ci joint un exemple d’une base de donnée endommagé qui possède des pages de données corrompus

Essayer d’interroger la table  [msdb].[dbo].[suspect_pages] pour récupérer le numéro de page endommagé

SELECT TOP (1000) [database_id]
,[file_id]
,[page_id]
,[event_type]
,[error_count]
,[last_update_date]
FROM [msdb].[dbo].[suspect_pages]

Ce ci est confirmé par la résultat du commande DBCC CHECKD 

maintenant on va procéder a réparer notre base de donnée on restaurant seulement la page endommagé (ici c’est la page n 312) sans que je serai obligé de restaurer la totalité de la base de donnée

Si vous préférez faire des restaurations de page avec l’interface utilisateur, voici les étapes:

Dans l’Explorateur d’objets SSMS, cliquez droit sur la base de données -> Tâches -> Restaurer puis cliquez sur Page

La fenêtre Restaurer la page sera ouverte.

2. Dans la fenêtre Restaurer la page, la base de données choisie est sélectionnée et la grille Pages est automatiquement remplie avec les pages endommagées (ici c’est celle qui porte le numéro 312) de la table msdb.dbo.suspect_pages (voir l’image ci-dessous)

L’étape finale consiste à cliquer sur le bouton OK et les pages endommagées sont restaurées.

À partir de la fenêtre Restaurer la page, vous pouvez exécuter DBCC CHECKDB pour déterminer si d’autres pages sont endommagées dans la base de données ou si vous souhaitez ajouter des pages supplémentaires si vous souhaitez utiliser

bonne réparation des pages Endommagée