SQL | AlexIn Tech

Comment fermer les connexions à une base de données MS SQL

Wed, 31 Jan 2024 00:00:00 +0000

Comment fermer les connexions à une base de données MS SQL

Lorsque vous essayez de mettre hors ligne une base de données dans Microsoft SQL Server et que cela ne fonctionne pas, cela signifie généralement qu’il y a des connexions actives ou des transactions qui empêchent l’opération de se terminer. Voici comment fermer les connexions à une base de données MS SQL et résoudre ce problème.

Identifier les connexions actives : Tout d’abord, vous devez déterminer s’il y a des connexions actives à votre base de données. Vous pouvez utiliser la requête SQL suivante pour cela :

USE master;
GO
SELECT spid, status, loginame, hostname, blocked, db_name(dbid) as dbname, cmd
FROM sys.sysprocesses
WHERE dbid = DB_ID('YourDatabaseName');

Remplacez ‘YourDatabaseName’ par le nom de votre base de données. Cette requête listera tous les processus connectés à votre base de données.

Tuer les connexions actives : S’il y a des connexions actives, vous pouvez les terminer. Utilisez la commande KILL suivie de l’ID de session (spid) pour chaque connexion :

KILL [session_id];

Remplacez [session_id] par le spid du processus que vous souhaitez terminer. Soyez prudent avec cette commande, car elle mettra fin immédiatement à la session sélectionnée et peut entraîner la perte de travaux non sauvegardés.

Enjoy 😎

AlexIn Tech

Comment détecter des Orphaned Users sur MS SQL Server

Tue, 30 Jan 2024 00:00:00 +0000

Comment détecter des Orphaned Users sur MS SQL Server

Bonjour à tous, c’est AlexIn Tech! Aujourd’hui, je vais partager avec vous une astuce technique que j’ai récemment utilisée lors de la migration d’un cluster SQL. J’avais besoin de vérifier l’existence d’“orphaned users” après avoir restauré ma base de données sur un nouveau cluster. Pour cela j’ai écrit un petit script TSQL et je vais vous l’expliquer en détail.

MS SQL Server

Qu’est-ce qu’un “Orphaned User” dans SQL Server?

Dans SQL Server, un “orphaned user” est un utilisateur de base de données qui n’est plus associé à une connexion valide au niveau de l’instance. Cela arrive souvent après la restauration d’une base de données dans un nouvel environnement.

Le Script pour Détecter les “Orphaned Users”

Voici mon petit script, il marche super.

-- Use your database
USE [YourDatabaseName];
GO

-- Create a temporary table to store user information
CREATE TABLE #DBUsers
(
 DBUserName NVARCHAR(128),
 DBUserSID VARBINARY(85)
);

-- Insert database user information into the temp table
INSERT INTO #DBUsers (DBUserName, DBUserSID)
SELECT name, sid
FROM sys.database_principals
WHERE type_desc IN ('SQL_USER', 'WINDOWS_USER', 'WINDOWS_GROUP');

-- Select and compare with instance logins
SELECT
 u.DBUserName AS DatabaseUser,
 u.DBUserSID AS DatabaseUserSID,
 p.name AS InstanceLogin,
 p.sid AS InstanceLoginSID,
 CASE
 WHEN p.sid IS NULL THEN 'Orphaned User'
 ELSE 'Matched'
 END AS Status
FROM
 #DBUsers u
LEFT JOIN
 sys.server_principals p ON u.DBUserSID = p.sid;

-- Drop the temporary table
DROP TABLE #DBUsers;

Explication du Script

Sélection de la Base de Données : Remplacez [YourDatabaseName] par le nom de votre base de données pour cibler celle-ci.
Création d’une Table Temporaire : Le script commence par créer une table temporaire #DBUsers. En TSQL, le préfixe # indique une table temporaire qui existe uniquement pendant la durée de la session et est stockée dans tempdb.**(lire la nota bene en bas d’articles pour plus d’infos)*
Insertion des Utilisateurs : Ensuite, il insère les noms et SID (Security Identifier) des utilisateurs de la base de données dans cette table temporaire.
Comparaison avec les Connexions de l’Instance : La requête principale compare les SID des utilisateurs de la base de données avec ceux des connexions de l’instance pour identifier les “orphaned users”.
Nettoyage : Enfin, la table temporaire est supprimée.

Comment Utiliser le Script?

Remplacez le Nom de la Base de Données : Commencez par remplacer [YourDatabaseName] par le nom de votre base de données.
Exécutez le Script : Lancez le script dans votre environnement SQL Server Management Studio (SSMS).
Analysez les Résultats : Les utilisateurs marqués ‘Orphaned User’ sont ceux que vous devez examiner.
Actions : Vous pouvez alors choisir de les supprimer ou de les relier à de nouvelles connexions.

Comprendre les Faux-Positifs parmi les “Orphaned Users”

Après avoir parcouru comment utiliser le script pour détecter les “orphaned users”, il est important de comprendre que, parfois, identifier un “orphaned user” ne signale pas forcément un problème. Dans certains cas, ces utilisateurs orphelins peuvent être des faux-positifs. Voici pourquoi :

Utilisateurs Supprimés de l’Active Directory (AD) : Il est courant après un restore de DB de trouver des utilisateurs qui existaient dans l’AD lors de la création de la base de données mais qui ont depuis été supprimés de l’AD. Ces comptes, bien que toujours présents dans la base de données comme utilisateurs, ne sont plus dans les logins de l’instance car lorsque les logins de l’instance ont été restaurés ils n’existaient plus dans l’AD. Cela génère donc des “orphaned users” car ils sont des les users de la DB mais pas dans les logins de l’instance. Assez souvent des vieilleries qui n’avaient pas été supprimées.
Utilisateurs Spécifiques à la Base de Données : Certaines bases de données ont des utilisateurs créés spécifiquement pour elles, sans correspondance au niveau de l’instance. Ces utilisateurs sont souvent conçus pour des rôles ou des fonctions spécifiques à la base de données et n’ont pas besoin de connexion au niveau de l’instance.

J’espère que ce guide vous aidera à gérer efficacement les utilisateurs dans vos bases de données SQL Server. Les “orphaned users” peuvent être un casse-tête, mais avec le bon outil, ils sont faciles à repérer et à gérer.

Enjoy 😎

AlexIn Tech

*Nota Bene : Pourquoi supprimer explicitement une table temporaire ?

Raisons de Supprimer Explicitement une Table Temporaire

Clarté et Bonnes Pratiques : L’inclusion d’une commande DROP TABLE pour les tables temporaires est souvent une question de clarté et de bonnes pratiques de développement. Elle indique clairement aux personnes qui lisent le script que la table n’est plus nécessaire et que son cycle de vie est géré de manière proactive.
Gestion des Ressources : Bien que SQL Server gère automatiquement la suppression des tables temporaires, le fait de les supprimer explicitement dès qu’elles ne sont plus nécessaires peut aider à libérer des ressources, comme la mémoire et l’espace disque dans tempdb, plus rapidement, surtout dans de longues sessions ou transactions.
Prévention des Conflits dans de Longues Sessions : Dans des sessions particulièrement longues ou complexes, où plusieurs opérations sont effectuées, supprimer explicitement une table temporaire dès qu’elle n’est plus utile peut aider à prévenir des conflits ou des confusions avec d’autres parties du script qui pourraient utiliser des tables temporaires avec des noms similaires.
Habitude et Portabilité : Pour les développeurs qui travaillent avec différents systèmes de gestion de base de données (SGBD), l’habitude de supprimer explicitement toutes les tables, y compris les temporaires, peut être une pratique courante. Cela assure une certaine uniformité dans la gestion des ressources, indépendamment des spécificités de chaque SGBD.

MSSQL - tempdb prend trop de place - disque FULL

Mon, 13 Mar 2023 00:00:00 +0000

MSSQL - tempdb prend trop de place - disque FULL

Salut à tous !

Aujourd’hui, on va parler de “tempdb”, une base de données système dans Microsoft SQL Server qui stocke des données temporaires telles que des tables temporaires et des variables de table, des plans d’exécution de requêtes et des résultats de requêtes intermédiaires. Cette base de données est essentielle au bon fonctionnement de SQL Server, et il est important de contrôler sa taille. (ça fait chelou avec les mots en français plutôt qu’en anglais mais vous comprenez, “temporary tables, table variable, query execution plan, query intermediary results, etc etc”)

Le problème que l’on va traiter concerne la croissance excessive de la base de données “tempdb”.

Pour déterminer la cause de ce problème, la première étape consiste à lancer SQL Server Management Studio et à accéder à la base de données “tempdb”.

On fait un clic droit sur la “tempdb” et ensuite => Tasks => Shrink => Files => Ne réduisez rien, regardez simplement l’espace disponible. Si l’espace disponible est élevé, cela indique qu’une requête mal optimisée est en cours d’exécution et que “tempdb” ne libère pas l’espace disponible.

Si l’espace disponible est faible, accédez à la base de données “tempdb” et exécutez un rapport standard, “Top Transactions by Age”, pour identifier si de nombreuses transactions sont ouvertes, ce qui pourrait provoquer la croissance de la base de données et la non-libération de l’espace.

Si cela ne renvoie rien, vous pouvez exécuter un script qui affiche tous les processus en cours d’exécution et la quantité d’espace qu’ils utilisent dans “tempdb”.

Le script suivant devrait fonctionner :

Who’s Using All that Space in tempdb, and What’s their Plan? - littlekendra.com

select
 t1.session_id
 , t1.request_id
 , task_alloc_GB = cast((t1.task_alloc_pages * 8./1024./1024.) as numeric(10,1))
 , task_dealloc_GB = cast((t1.task_dealloc_pages * 8./1024./1024.) as numeric(10,1))
 , host= case when t1.session_id <= 50 then 'SYS' else s1.host_name end
 , s1.login_name
 , s1.status
 , s1.last_request_start_time
 , s1.last_request_end_time
 , s1.row_count
 , s1.transaction_isolation_level
 , query_text=
 coalesce((SELECT SUBSTRING(text, t2.statement_start_offset/2 + 1,
 (CASE WHEN statement_end_offset = -1THEN LEN(CONVERT(nvarchar(max),text)) * 2ELSE statement_end_offset
 END - t2.statement_start_offset)/2)
 FROM sys.dm_exec_sql_text(t2.sql_handle)) , 'Not currently executing')
 , query_plan=(SELECT query_plan from sys.dm_exec_query_plan(t2.plan_handle))
from
 (Select session_id, request_id
 , task_alloc_pages=sum(internal_objects_alloc_page_count + user_objects_alloc_page_count)
 , task_dealloc_pages = sum (internal_objects_dealloc_page_count + user_objects_dealloc_page_count)
 from sys.dm_db_task_space_usage
 group by session_id, request_id) as t1
left join sys.dm_exec_requests as t2 on
 t1.session_id = t2.session_id
 and t1.request_id = t2.request_id
left join sys.dm_exec_sessions as s1 on
 t1.session_id=s1.session_id
where
 t1.session_id > 50 -- ignore system unless you suspect there's a problem there
 and t1.session_id <> @@SPID -- ignore this request itself
order by t1.task_alloc_pages DESC;
GO

Une fois que vous avez toutes ces informations, vous pouvez commencer à trouver la cause de ce problème de taille excessive et savoir exactement “qui” ou “quoi” utilise l’espace.

Pour corriger ce problème de manière temporaire, redémarrez simplement SQL Server, ce qui effacera le fichier journal de la “tempdb”. Ensuite vous pouvez modifier les paramètres de l’auto-growth et afin de mettre une taille fixe ou désactiver ce settings. Logiquement la query qui pose problème n’arrivera plus à s’exécuter et on devrait trouver le coupable.

En suivant ces étapes, vous pouvez facilement identifier la cause de la croissance excessive de “tempdb” et résoudre le problème.

J’espère que cet article vous a été utile. À bientôt !

Obtenir le port d'une instance SQL en Powershell

Thu, 12 Aug 2021 00:00:00 +0000

Obtenir le port d’une instance SQL en Powershell

Le port par défaut d’un serveur MS SQL est le 1433 mais vous trouverez souvent que, par mesure de sécurité, le port a été modifié.

Voici un petit script PowerShell permettant de retourner les instances ainsi que les ports utilisés d’un serveur MS SQL.

$server = Read-Host -Prompt 'Input your servername'

$namespace = gwmi -computername $server -Namespace "root\microsoft\sqlserver" -Class "__Namespace" -Filter "name like 'ComputerManagement%'" | sort desc | select -ExpandProperty name -First 1

Get-WmiObject -computername $server -Namespace "root\microsoft\SqlServer\$namespace" -Class ServerNetworkProtocolProperty | select instancename,propertystrval,PropertyName,IPAddressName,ProtocolName | where{$_.IPAddressName -eq 'IPAll' -and $_.propertystrval -ne ''} | ft -autosize

Lorsque vous exécuterez ce script, il vous demandera de rentrer le serveur pour lequel vous souhaitez trouver les instances et ports et vous obtiendrez le résultat suivant :

Enjoy ! 😉

Retourner la date des derniers backups pour toutes les DBs d'une instance MS SQL

Tue, 30 Mar 2021 00:00:00 +0000

Retourner la date des derniers backups pour toutes les DBs d’une instance MS SQL

Voici un petit script SQL bien pratique pour savoir quand vos bases ont été backupées pour la dernière fois sur une instance MS SQL.

SELECT sdb.Name AS DatabaseName,
COALESCE(CONVERT(VARCHAR(12), MAX(bus.backup_finish_date), 101),'-') AS LastBackUpTime
FROM sys.sysdatabases sdb
LEFT OUTER JOIN msdb.dbo.backupset bus ON bus.database_name = sdb.name
GROUP BY sdb.Name

Enjoy ! ;-)