PI Services

Le blog des collaborateurs de PI Services

SQL Server–La suppression du contenu d’une table ne se termine pas

Contexte

Afin de purger une table, deux solution sont possibles :

“TRUNCATE table Table_a_vider” ou “DELETE from Table_a_vider”

La principale différence entre ces deux commandes est la suivante :

  • TRUNCATE est une commande DDL, cette commande est beaucoup plus rapide, mais son action est irrémédiable,
  • DELETE est une commande DML, sa durée d’exécution dépends du volume de données à traiter.

Ces deux commandes ont malgré tout pour point commun de nécessiter un lock exclusif sur les données à supprimer. Si ce lock n’est pas obtenu, la commande vas continuer de s’exécuter jusqu’à l’obtenir.

Afin de ne pas attendre, il faut détecter la session provoquant le blocage et la stopper si possible.

Résolution

La commande suivante permet de lister toutes les transactions bloquées :

USE Master
GO
SELECT *
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;
GO

La commande sp_who2 liste toute les sessions avec leur numéro de SPID, il suffit de retrouver la session remontée par la commande précédente puis de se référer à la colonne “BlkBy” afin d’identifier le process qui la bloque.

image_thumb1

La commande suivante permet d’afficher la commande exécutée par le SPID indiqué, cela permet d’évaluer le risque avant de stopper la session à l’aide de la commande “kill”

dbcc inputbuffer(SPID)

SQL Server–Création d’un job de Vérification de cohérence d’une base SQL

Contexte

Ce post explique comment créer un job qui permet de vérifier automatiquement la cohérence d’une base de donnée.

Résolution

Depuis SQL Server Management Studio, depuis le dossier “Management”, créer un nouveau plan de maintenance :

image

Ajouter la tâche de vérification de l’intégrité de la base depuis la ToolBox :

image_thumb5_thumb

Indiquer les bases à vérifier :

image_thumb7_thumb

Eventuellement, indiquer l’action à réaliser en cas de succès ou d’échec du job :

image_thumb9_thumb

SQL Server–Restaurer une base de données sous un nom logique différent

Contexte

Ce post explique comment restaurer une base de donnée sous un différent nom/emplacement

Résolution

Récupérer le nom logique de la base :

RESTORE FILELISTONLY FROM DISK='c:\backup.bak'

Restaurer la base sous un autre nom logique / emplacement :

RESTORE DATABASE NouveauNomLogique FROM DISK='c:\backup.bak'
WITH 
   MOVE 'NomLogiqueduMDF' TO 'c:\NouveauNomLogiqueduMDF.mdf',
   MOVE 'NomLogiqueduLDF' TO 'c:\NouveauNomLogiqueduLDF_log.ldf'

Windows Server–Démarrer automatiquement un DCS suite à un reboot

Contexte

Suite à un reboot, l’exécution d’un data collector set créé depuis Perfmon est interrompue.

La console PerfMon permet uniquement de planifier le lancement d’un DCS en fonction de dates spécifiques et non en fonction d’un évènement :

image

Ce post explique comment automatiquement lancer un Data Collector Set à chaque démarrage du serveur.

Résolution

Depuis le Task Scheduler naviguer vers “Library -> Microsoft -> Windows –> PLA” :

image

Sélectionner le DCS souhaité puis ajouter un trigger du type “At system startup” :

image

Windows Server–SYSPREP une machine plus de trois fois

Contexte

Sur une même machine Windows, il est impossible de réaliser plus de 3 sysprep, au bout de la 4eme tentative, l’utilitaire sysprep affiche l’erreur suivante :

image

Microsoft recommande d’utiliser une image d’un système “sysprepé” afin de contourner cette limite.

Cette limite a été mise en place afin que sysprep ne soit pas utilisé pour réinitialiser la période de grâce de 30 jours que Microsoft fourni pour activer la licence.

Résolution

Pour sysprep une même machine plus de trois fois, les étapes suivantes doivent être réalisées :

1. Depuis l’éditeur de registre,

Depuis la l’entrée “HKEY_LOCAL_MACHINE\System\Setup\Status\SysprepStatus”, modifier la valeur de la clé “CleanupState” à 2 et la valeur de la clé “GeneralizationState” à 7 :

image

Depuis la l’entrée “HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\SoftwareProtectionPlatform”, modifier la valeur de la clé “SkipRearm” à 1 :

image

2. Depuis un command prompt lancé en tant qu’administrateur,

Exécuter les commandes suivantes :

msdtc -uninstall
msdtc -install

3. Depuis le répertoire “C:\Windows\System32\Sysprep” supprimer le dossier “Panther” :

image

SQL Server–Détecter et modifier les comptes utilisés pour l’exécution de jobs

Contexte

Il arrive souvent qu’un compte utilisateur soit utilisé pour l’exécution d’un job SQL, il s’agit d’une mauvaise pratique car le compte utilisateur peut être amené à changer de mot de passe ce qui provoqueras une erreur d’exécution des jobs en question.

Ce post explique comment détecter puis modifier les comptes utilisés.

Analyse

Le script suivant permet de détecter les jobs exécuté via un compte user (DOMAIN\USER-%) tout en ne remontant pas les jobs lancés par un compte de service (DOMAIN\SERVICE-%).

Les variables “DOMAIN\USER-%” et “DOMAIN\SERVICE-%” sont à modifier en fonction de la nomenclature utilisée pour nommer les comptes. Le “%” correspond à toute chaîne de zéro caractères ou plus Ce caractère générique peut être utilisé comme préfixe ou comme suffixe.

select s.name,l.name
from  msdb..sysjobs s
  left join master.sys.syslogins l on s.owner_sid = l.sid
where l.name like 'DOMAIN\USER-%' and  l.name not like 'DOMAIN\SERVICE-%'

Résolution

Il faut ensuite récupérer le SID du compte utilisateur à changer depuis l’active directory, ainsi que le SID du compte à utiliser, par exemple, SA.

Pour récupérer le SID d’un utilisateur SQL, executer la commande suivante “select sid,name,denylogin from MASTER..syslogins where name='SQLUser'”

Le script suivant permet de modifier l’owner des jobs d’une instance SQL depuis le SID “0x02” vers le SID “0x01” :

UPDATE msdb..sysjobs
SET owner_sid = CONVERT(varbinary(max), '0x01', 1)
where owner_sid = CONVERT(varbinary(max), '0x02', 1)

SQL SSRS–Renouvellement de certificat

Contexte

Lors d’un renouvellement de certificat WEB sur une instance SSRS, le mapping du nouveau certificat échoue avec l’erreur suivante :

Microsoft.ReportingServices.WmiProvider.WMIProviderException: An SSL binding already exists for the specified IP address and port combination. The existing binding uses a different certificate from the current request. Only one certificate can be used for each IP address and port combination. To correct the problem, either use the same certificate as the existing binding, or remove the existing SSL binding and create a new binding using the certificate of the current request.

Explication

Le message d’erreur précise que la combinaison IP:Port est déjà mappée à un certificat existant (celui que l’on tente de renouveler).

La commande suivante permet de visualiser le binding existant :

netsh http show sslcert

image

On remarque que le certificat que l’on tente de renouveller est mappé à la combinaison IP:Port suivante : [::]:443

Résolution

A l’aide de la commande précédemment citée, récupérer la combinaison IP:Port utilisée par le certificat que l’on tente de renouveler, puis supprimer le mappage à l’aide de la commande suivante :

netsh http delete sslcert ipport=[::]:443



DNS–Impossible de supprimer une Zone

Contexte

Depuis une console lancée en tant qu’administrateur du domaine il est impossible de supprimer une zone DNS existante, une erreur de type “AccessDenied” est retournée :

image

Explication

En investiguant sur la cause de cette erreur, on remarque qu’une ACE refuse au groupe Tout le Monde de supprimer cet objet :

image

Cette ACE est en fait créée automatiquement lorsque la protection contre la suppression accidentelle est activée.

Résolution

Après la suppression de cette entrée, il est possible de supprimer l’objet sans erreurs.

SQL Server Mirroring–Réactiver le mirroring sur une base suspendue

Contexte

La mise en miroir des bases de données est une solution de haute-disponibilité fournie par SQL Server depuis la version 2005. Cette fonctionnalité s’implémente au niveau de chaque base de donnée.

L’avantage de cette solution est de disposer d’une base de donnée active en tout temps, ce qui permet de réaliser des maintenances sur un serveur sans interrompre l’accès aux bases utilisées par des application clientes.

Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez à la place Groupes de disponibilité Always On.

Cause

Voici les principales causes provoquant une interruption de la replication Mirroring :

  • Les serveurs partner (+ eventuellement witness) ne communiquent pas correctemment,
  • Erreur d’espace disque sur l’un des serveurs partner,
  • Changement du recovery model sur le serveur principal (le mirroring requière le recovery model Full).

Résolution

La commande suivante exécutée sur l’un des serveur partner permet de rétablir la réplication :

ALTER DATABASE DATABASE SET PARTNER RESUME

SQL Server–Optimiser les paramètre d’exécution parallèle (1/2)

Introduction :

SQL Server est conçu pour optimiser l’exécution des requêtes de manière transparente, l’une des méthodes utilisé par SQL est le calcul parallélisé de requêtes.

Cette méthode d’optimisation consiste à diviser l’exécution d’une requête à travers threads afin d’accélérer l’exécution de la requête.

Ce post composé de deux parties à pour objectif de présenter les paramètres suivants :

  • MAXDOP (partie 1/2),
  • Cost Threshold for Parallelism (partie 2/2)

Explication :

Le paramètre MAXDOP signifie “Max Degree of Parallelism”, ce paramètre permet de maitriser le nombre maximum de processeurs pouvant intervenir dans l’exécution d’une requête parallélisée, il est important de comprendre que ce paramètre ne peut être utilisé pour limiter le nombre de processeurs utilisés par SQL.

Ce lien liste les valeur recommandées par Microsoft afin de paramétrer cette valeur en fonction des versions de SQL Serveur, ce lien peut également être utilisé pour calculer la valeur optimale à positionner. Il est bien entendu nécessaire de tester les différentes configurations en fonction de la charge soumise par l’application qui utilise le serveur SQL.

Réalisation

Le paramètre MAXDOP peut être modifié depuis les propriétés de l’instance SQL concernée dans la partie Advanced->Parallelism :

image

Ou via la requête suivante (en remplaçant VALEUR par la valeur désirée) :

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
dbo.sp_configure 'max degree of parallelism', VALEUR;
GO

RECONFIGURE;
GO

La modification du paramètre MAXDOP est prise en compte sans qu’il n’y a à redémarrerredemmarer l’instance.

Sources :