Introduction

Ce post est composé de deux parties :

• Recommandations sur l’emplacement et la taille de TempDB (Partie 1)
• Répartition de la base TempDB sur plusieurs fichiers (Partie 2)

Dans cette seconde partie nous verrons comment repartir la base TempDB à travers plusieurs fichiers comme Microsoft le recommande.

Recommendation

Bien que Microsoft recommande de répartie la base TempDB à travers autant de fichiers que de processeurs logiques présents sur le serveur et ce jusqu’à 8 fichiers, dans le cas d’un serveur avec plus de 8 CPU, si malgré l’utilisation de 8 fichiers la base TempDB souffre toujours de lenteurs, Microsoft préconise d’augmenter le nombre de fichiers par un multiple de 4.

Différents membres de la communauté SQL s’accordent à penser qu’au-delà de 8 fichiers, le gain en performance seras négligeable par rapport à l’effort d’administration.

Réalisation

Avec SQL Server 2016 nous aurions la possibilité de configurer la base de données tempdb dans le cadre du processus d'installation.

Un nouvel onglet a été ajouté à la rubrique de configuration du serveur de base de donnés sous le nom de tempdb et il nous permettra de préciser :

1. Le nombre de fichiers de données de la base de données tempdb
2. La taille initiale de chaque fichier et le taux de croissance en Mb
3. La possibilité d'ajouter plusieurs emplacements pour le stockage des fichiers tempdb
4. L'emplacement et la taille du fichier log de la base de données tempdb

Contexte

Le log shipping est l’une des technologies proposée par SQL Server pour mettre en place une haute-disponibilité d’une ou plusieurs bases de données à moindre prix.

Le fonctionnement du log shipping peux être résumé en trois étapes “backup-copy-restore”.

Les logs de transactions des bases de donnée à répliquer sont sauvegardées depuis le serveur primaire puis copiés vers le (ou les) serveur secondaire où ils y seront restaurés sur les bases secondaires correspondantes.

Plus d’informations sur le fonctionnement du log shipping sont disponibles ici.

Prérequis

Les prérequis à l’installation sont les suivants :

Prérequis Applicatifs :

• Au moins deux serveurs avec SQL Server 2005 (Standard, Entreprise ou Workgroup) ou ultérieur,
• Un partage de fichier pour la copie des logs de transactions,
• Le service SQL Server Agent,
• Il est fortement conseillé d’avoir des instances SQL partenaires configurés à l’identique.

Permissions nécessaires :

• Disposer des droits sysadmin sur l’instance primaire et la secondaire,

Configuration du log shipping

Les actions décrites sont effectuées depuis le serveur primaire.

1. Vérifier que la base de donnée à répliquer est en mode de recovery “full” ou “bulk-logged” à l’aide de la requête suivante :

2. Depuis les propriétés de la base à répliquer, depuis l’onglet “Transaction Log Shipping” (1) cochez la case “Enable this as a primary database in a log shipping configuration” (2) puis cliquer sur “Backup Settings” (3) :

3. Depuis la fenêtre Backup Settings, indiquer le chemin réseau où le serveur primaire écriras les backups des logs de transactions des bases de données à répliquer (1) et éventuellement le chemin local (2) si un chemin local est utilisé. Noter que dans les deux cas le compte utilisé par le service SQL Server Agent du serveur secondaire doit avoir un accès en lecture à ce dossier, et le service SQL Server du serveur primaire doit avoir un accès en read/write.

Indiquer le nom du job de backup du serveur primaire (3) de manière à facilement le reconnaitre, éventuellement modifier le schedule proposé (4) par un schedule correspondant mieux à vos contraintes spécifiques puis cliquer sur OK.

4. Depuis la fenêtre Secondary Database Settings, se connecter au serveur secondaire (1), choisir une base de donnée existante ou indiquer le nom d’une nouvelle base (2) qui seras utilisée/créée sur le serveur secondaire, puis choisir le mode pour initialiser la base de donnée secondaire.

Ayant déjà créé initialisé la base distante, j’ai choisi l’option “No, the secondary database is initialized” (3)

5. Depuis l’onglet “Copy Files” (1), indiquer le chemin où les sauvegardes des logs de transactions seront copiés (2), indiquer la rétention des fichiers copiés (3) en faisant attention à ce que les fichiers ne soient pas supprimés avant leur restauration sur le serveur secondaire, personnaliser le nom du job de copie (4) et modifier son schedule si nécessaire (5)

6. Depuis l’onglet “Restore Transaction Logs” (1), choisir “Standby Mode” et cocher la case “Dissconnet users in the database when restoring backups” (2) celà permet d’accéder à la base de données secondaire en Read-Only contrairement au mode “No-Recovery” qui met la base en état de restauration, personnaliser le nom du job de restauration (3) et en modifier le schedule si nécessaire (4)

Vérification

Il convient suite à la mise en place du log shipping de vérifier son fonctionnement en mode manuel (c-à-d en exécutant manuellement les jobs de Backup-Copy-Restore) et automatiquement selon les schedule définis pour chaque jobs.

Il est possible de mettre en place des alertes par email pour informer le DBA de la bonne exécution des jobs de réplication depuis l’onglet Transaction log shipping des propriétés de la base répliquée.

SQL Server 2012 cache quelques petites nouveautés qui peuvent bien vous surprendre.

J’ai découvert récemment qu’il est désormais possible de reconstruction un index en ligne sur SQL Server 2012 de tables qui contiennent des types VARCHAR(MAX) et NVARCHAR(MAX).

Démonstration :

Commencez par exécuter le script sous SQL Server 2008 R2 puis sur SQL Server 2012.

USE [tempdb]
GO
CREATE TABLE T1
(ID INT, C1 NVARCHAR(10), C2 NVARCHAR(MAX))
GO
CREATE CLUSTERED INDEX [IX_T1]
ON T1
(ID)
GO
CREATE NONCLUSTERED INDEX [IX_T1_Cols]
ON T1
(C1)
INCLUDE (C2)
GO
USE [tempdb]
GO
ALTER INDEX [IX_T1_Cols] ON [dbo].[T1]
REBUILD WITH (ONLINE = ON)
GO
DROP TABLE T1
GO

Résultat :

Sur le serveur SQL Server 2008 R2, on a un message d’erreur du type

Msg 2725, Level 16, State 2, Line 1
An online operation cannot be performed for index ‘IX_T1_Cols’ because the index contains column ‘C2’ of data type text, ntext, image, varchar(max), nvarchar(max), varbinary(max), xml, or large CLR type. For a non-clustered index, the column could be an include column of the index. For a clustered index, the column could be any column of the table. If DROP_EXISTING is used, the column could be part of a new or old index. The operation must be performed offline.

Tandis que sur le serveur SQL Server 2012

Command(s) completed successfully.

Lors d’une mission d’installation de SQL Server chez un client, j’ai rencontré un problème d’installation du service SQL Server Reporting suite à une réinstallation du serveur.

L’erreur en question mentionne que le service SQL Server Reporting ne peut pas etre installé car il existe une instance du même nom sur le serveur.

An instance with the same name is already installed on this computer. To proceed with SQL Server Setup, provide a unique instance name.

Pour résoudre ce problème :

1. Commencez par désinstaller tous les binaires de SQL Server 2005

2. Supprimez le dossier correspondant à C:\Program Files\Microsoft SQL Server\, ou spécifiquement le dossier C:\Program Files\Microsoft SQL Server\MSSQL.1.

3. Puis ouvrez l’éditeur du registre recherchez les clés suivantes pour les supprimer :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSSQLServer

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\MSSQL.1

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\Services\SQL Server

4. Puis redémarrer votre serveur et relancez votre installation.

Dans le cadre de l’administration de serveurs de base de données, vous serez probablement un jour amené à comparer des bases de données entre elles.

La procédure ci-dessous vous aide à comparer deux bases de données entre à l’aide de SQL Server Data Tools 2012.

1. Commencez par télécharger le SQL Server Data Tools de Visual Studio 2012 en suivant ce lien :

http://msdn.microsoft.com/en-us/jj650015

Cliquez ensuite sur le lien Download SQL Server Data Tools for Visual Studio 2012

2. Une fois que votre outil est téléchargé, installez le puis lancez le SQL Server Data Tools.

L’icône ressemble à cette image :

3. Dans le menu SQL, sélectionnez Comparaison de schémas puis cliquez sur Nouvelle comparaison de schémas…

4. Sélectionnez dans un premier temps la source en cliquant sur Sélectionner source…

5. Cliquez sur Nouvelle connexion… pour choisir la base de données d’un serveur que vous désirez mettre en source.

6. Choisissez le nom du serveur puis votre base de données hébergée sur ce dernier.

a. Dans l’exemple ci-dessous notre serveur se nomme JELAV-HP-01\SQL2012 et notre base de données source se prénomme AdventureWorks2012

b. Cliquez ensuite sur OK

7. Cliquez sur OK.

8. Sélectionnez maintenant votre base de données cible en cliquant sur Sélectionner cible…

9. Une fenêtre de sélection pour le schéma cible apparait. Cliquez sur Nouvelle connexion… pour ajouter la base de données cible que vous souhaitez.

10. Choisissez le nom du serveur puis votre base de données hébergée sur ce dernier.

a. Dans l’exemple ci-dessous notre serveur se nomme JELAV-HP-01\SQL2008R2 et notre base de données cible se prénomme AdventureWorks2008R2

b. Cliquez ensuite sur OK

11. Cliquez à nouveau sur OK.

12. Vos deux champs Source et Cible sont renseignés, vous pouvez maintenant comparer le schéma des deux bases de données en cliquant sur l’icône Comparer.

13. Une fois que la comparaison des schémas est terminée, dans notre exemple nous observons des objets qui comportent des points de divergence. Nous avons la possibilité de mettre à jour le schéma cible pour que le schéma de la base de données AdventureWorks2008R2 soit identique de celle de AdventureWorks2012.

14. Pour mettre à jour, le schéma de la base de données cible, cliquez sur l’icône Mettre à jour.

15. Une fenêtre apparait pour vous avertir et vous demander confirmation, cliquez sur Oui.

16. Une fois que la mise à jour est achevée, vous pouvez voir le détail des opérations dans le menu Opérations des outils de données et le succès de celui-ci.

17. Relancez la comparaison des deux schémas pour valider la mise à jour. Résultat de la comparaison, le schéma des deux bases de données sont identique.

Dans certains cas un message d’erreur est renvoyé lors de l’exécution de rapports sous SQL Reporting Services faisant état d’un lien invalide:

Si vous ouvrez le même rapport directement depuis le site web de votre instance Reporting Services (Dans cet exemple un rapport sur les performances mémoire de Sharepoint), le message est effectivement le même.

Pour corriger cela, ouvrez les propriétés du rapport, toujours sur le même site (Pas le fichier .rdpl, mais le fichier du même nom, qui n’a pas d’extension affiché) et sélectionnez Gérer.

A présent il faut cliquer sur Changer le lien. Vous pouvez vous referez a un environnement de test, de preprod, pour voir quel est le lien vers la définition du rapport (Dans cet exemple il s’agit d’un rapport issu de System Center Operations Manager. La majorité des rapports de performance sont rattaché a Microsoft.SystemCenter.Datawarehouse.Report.Performance).

Cliquez sur Changer le lien, sélectionnez la définition du rapport et cliquez OK

Le rapport a récupéré son lien. Cliquez Sur Appliquer.

Et il est a nouveau disponible a l’exécution:

Problématique

Dans certains cas nous somme amené à utiliser l’instruction BULK INSERT pour injecter dans une table des enregistrements qui proviennent d’un fichier texte stocké sur un partage réseau

Supposons maintenant que nous disposons de 3 serveurs :

• 1 contrôleur de domaine DC01
• 2 serveurs SQL 2008 R2 SQL01 et SQL02, le serveur SQL01

Dans le premier scénario nous allons exécuter une requête BULK INSERT sur le serveur SQL01 qui injectera dans la table #TEST les lignes d’un fichier texte nommé ListCustomers.txt accessible via le chemin UNC \\SQL01\FILES\Input

Dans ce premier scénario la requête aboutit sans aucun problème  

Dans le deuxième scénario nous allons exécuter une requête BULK INSERT sur le serveur SQL01 mais depuis le serveur SQL02 qui injectera dans la table #TEST les lignes d’un fichier texte nommé ListCustomers.txt accessible via le chemin UNC \\SQL01\FILES\Input

Dans ce deuxième scénario la requête aboutit sans aucun problème

Dans le troisième scénario nous allons exécuter une requête BULK INSERT sur le serveur SQL01 mais depuis le serveur SQL02 qui injectera dans la table #TEST les lignes d’un fichier texte nommé ListCustomers.txt accessible via le chemin UNC \\SQL02\FILES\Input

Dans ce troisième scénario une erreur est générée, en effet l’instruction BULK INSERT n’arrive pas à ouvrir le fichier source pour y lire les enregistrements !

 

Le message complet de l’erreur peut être:

Explication

L’erreur enregistrée dans le scénario 3 est dû au fait que lorsqu’un utilisateur se connecte à SQL Server avec l’authentification Windows il n’est autorisé à lire que les fichiers accessibles par le biais de son compte utilisateurs, quelque soit le profil de sécurité du processus SQL Server.

Résolution

Pour remédier à ce problème on pourra procéder de deux manières, soit qu’on utilise une connexion SQL Server au lieu de l’authentification Windows soit configurer Windows pour activer la délégation des comptes de sécurité.

Pour la configuration de Windows il faudra procéder comme suit :

Supposons  que le compte de service utilisé pour le démarrage du service SQL sur le serveur  SQL01 est SvcSQL01 alors il faudra créer un SPN sur ce compte en utilisant la commande suivante :

SETSPN –A MSSQLSvc/SQL01.domain.lan:1433 DOMAIN\SvcSQL01

Pour vérifier que l’SPN a été bien créé on peut exécuter la commande suivante :

SETSPN –L DOMAIN\SvcSQL01

Une fois le nom principal de service créé il faudra approuver le compte SvcSQL01 à la délégation et le compte de la machine  SQL01 à la délégation, ceci se fait via la console Utilisateurs et Ordinateurs Active Directory

Attention : l’onglet “Delegation” n’apparaitra sur le compte SvcSQL01 qu’après avoir créé le nom principal de servie avec la commande SETSPN 

On peut vérifier maintenant que la requête ne gènère plus d’erreur comme le montre la figure suivante.

l’exécution de la requête

SELECT session_id, auth_scheme FROM sys.dm_exec_connections nous permet de confirmer l’authentification utilisé pour nitre session est bien KERBEROS 

Remarque

Nous avons pu remarquer que si nous créons le nom principal de service avec le nom de l’instance et non le numéro de port d’une instance nommée l’erreur 4861 persiste, il a fallut fixer le port utilisé par l’instance et l’utiliser pour la configuration du nom principal du service lié au compte de service SQL. 

Ce script permet d’obtenir des informations sur les propriétés des bases de données utiles à un administrateur de bases de données afin de prendre des décisions.

Résultat :

Ce script très utile pour des travaux d’inventaire ou de statistiques, permet de compter le nombre de lignes que disposent les tables d’une base de données :

USE [DB]
GO
SELECT OBJECT_NAME(OBJECT_ID) TableName, st.row_count
FROM sys.dm_db_partition_stats st
WHERE index_id < 2
ORDER BY st.row_count DESC
GO