babaluga

La base de données système Master est la base dans laquelle les sessions se connectent par défaut. Combien de fois, lorsque vous ouvrez une session sur SQL Server, à travers Management Studio, ne vous êtes-vous pas retrouvés sur la base Master ? En général, on crée un objet, et on ne s’aperçois qu’après coup qu’on l’a fait au mauvais endroit.

Le meilleur moyen d’éviter cela, est de changer la base de données pardéfaut de votre login :
ALTER LOGIN moi WITH DEFAULT_DATABASE = une_autre_base_que_master

Si vous ne pouvez pas faire cela, voici un truc qui utilise les déclencheurs DDL, et qui annule la transaction de création d’objet, si vous êtes dans Master :

USE Master
GO

CREATE TRIGGER IamInMaster
ON DATABASE
FOR DDL_DATABASE_LEVEL_EVENTS
AS BEGIN
	IF EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]', 'sysname') = 'Master'
		AND EVENTDATA().value('(/EVENT_INSTANCE/EventType)[1]', 'char(6)') = 'CREATE'
	BEGIN
		RAISERROR ('Vous êtes dans Master', 16, 10)
		ROLLBACK
	END
END

Lorsque le noeud actif du cluster bascule, pour cause de défaillance, il n’y a pas de notification particulière envoyée. Vous pouvez sans doute utiliser un outil de supervision qui envoie des messages à partir du journal d’événements de Windows, ou créer une alerte spécifique, ou une notification d’événement. Une solution très simple consiste à créer une procédure stockée activée au démarrage du service SQL, qui peut envoyer un e-mail par Database Mail, ou écrire dans une une table. Voici un exemple simple de procédure stockée déclenchée au démarrage, qui vous indique en plus comment savoir sur quel noeud du cluster le service SQL est en activité :

USE master; 

GO
EXEC sp_configure 'show advanced option', '1';
RECONFIGURE
EXEC sp_configure 'scan for startup procs', '1';
RECONFIGURE 

/*
- la sproc doit être dans Master
- elle doit appartenir au schéma DBO
- pas de paramètres !
*/ 

CREATE TABLE dbo.AuditDemarrage (
    Qui sysname NOT NULL DEFAULT (CAST(SERVERPROPERTY('ComputerNamePhysicalNetBIOS') as sysname)),
    Quand datetime NOT NULL DEFAULT (GetDate())
)
GO 

CREATE PROC dbo.InsertAuditDemarrage
AS
    INSERT INTO dbo.AuditDemarrage DEFAULT VALUES
GO 

exec sp_procoption N'InsertAuditDemarrage', 'startup', 'on'
GO 

SELECT * FROM dbo.AuditDemarrage

SQL Server 2000 était connu pour gérer de manière imparfaite le parallélisme dans le cas des processeurs hyperthreadés. Je ne suis pas sûr que SQL Server 2005 s’améliore beaucoup de ce point de vue, mais je n’ai pas eu l’occasion de tester ce type de configuration sur 2005.
Exécuter une requête sur plusieurs processeurs simultanément reste une décision qui parfois peut se révéler délicate. SQL Server fait ce choix par rapport à la charge actuelle des différents CPU, selon sont estimation du coût estimé de la requête. Si les processeurs sont peu chargés et la requête paraît coûteuse, SQL Server peut choisir de paralléliser certaines opérations. Evidemment, le gain est plus effectif sur des systèmes qui exécutent peu de requête, de grands volumes. Par contre, plus le serveur doit supporter la concurrence, moins le parallélisme est approprié : des CPUs occupés à servir la même requête sont indisponibles pour servir les demandes entrantes.
Si vous voulez augmenter la limite de coût qui peut déclencher une parallélisation, changez l’option de serveur cost threshold for parallelism , en indiquant un coût estimé en secondes :

sp_configure 'show advanced options', 1;
reconfigure;
GO
sp_configure 'cost threshold for parallelism', 10;
reconfigure;
GO

Pour placer la limite à 10 secondes.

Pour modifier le nombre de processeurs qui pourront être utilisés pour une seule requête :

EXEC sp_configure 'show advanced options', 1
RECONFIGURE
EXEC sp_configure 'max degree of parallelism', 1
RECONFIGURE


Cette commande, par exemple, annule tout parallélisme en ne permettant à SQL Server de n’utiliser qu’un seul processeur.

Vous pouvez également limiter le parallélisme par requête, en utilisant une option de requête :

SELECT * FROM ...
OPTION(MAXDOP 1)


Identity est le mot-clé utilisé pour créer une colonne auto-incrémentale en SQL Server.
Vous ne pouvez avoir qu’une seule colonne à la propriété IDENTITY par table.

Vous avez à votre disposition trois fonctions pour retrouver la dernière valeur IDENTITY :
@@IDENTITY – vous retourne la dernière valeur IDENTITY générée dans votre session, y compris d’une manière invisible si vous avez un déclencheur sur la table recevant l’insertion, qui lui-même insère dans une table. Pour éviter ce problème, et en règle générale, préférez la fonction :
SCOPE_IDENTITY() – qui retourne la dernière valeur IDENTITY insérée dans la portée de votre code.

Une dernière fonction :
IDENT_CURRENT() – vous retourne la dernière valeur IDENTITY insérée dans une table donnée (passée en paramètre), quel que soit le contexte et la session.

Attention aux bibliothèques clients délicates : les valeurs de retour de ces fonctions sont numeric, quel que soit le type de la colonne IDENTITY. Vous pouvez le constater avec la requête suivante :
SELECT SQL_VARIANT_PROPERTY(@@IDENTITY, 'BaseType')
Si besoin est, faites un CAST explicite.