babaluga

SELECT j.name, j.description, js.step_name, js.command
FROM msdb.dbo.sysjobs_view j
JOIN msdb.dbo.sysjobsteps js ON j.job_id = js.job_id
ORDER BY j.name, js.step_id

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.

Grâce à un post dans un forum SQL Server, je viens de découvrir une fonctionnalité utile que j’ignorais : la possibilité de créer une trace de type boîte noire, permettant de conserver les dernières commandes SQL envoyées au serveur avant un crash de celui-ci. Il y a pour ce faire une option de sp_trace_create: TRACE_PRODUCE_BLACKBOX. SQL Server crée un fichier de trace nommé blackbox.trc contenant 5 mb des dernières instructions SQL.

Une entrée de la knowledge base sur le sujet : Stored Procedure to Create a SQL Server 2000 Blackbox Trace

Pour insérer dans une table qui comporte des colonnes calculées indexées, un certain nombre d’options de la connexion doivent être settées, afin de garantir la consistence des données insérées

ces options sont :

SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON
SET NUMERIC_ROUNDABORT OFF

Certaines options sont liées à la sproc à sa création. Si par exemple vous avez des messages d’erreur à l’exécution de la procédure malgré les settings de la connexion, regardez quelles options étaient settées à la création de la sproc, Exemple pour ANSI_NULLS et QUOTED_IDENTIFIER :

SELECT
	ROUTINE_NAME,
	OBJECTPROPERTY(OBJECT_ID(ROUTINE_NAME), 'ExecIsQuotedIdentOn') as IsQuotedIdentOn,
	OBJECTPROPERTY(OBJECT_ID(ROUTINE_NAME), 'ExecIsAnsiNullsOn') as ExecIsAnsiNullsOn
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_NAME = 'maprocedure'

Si vous trouvez un 0 dans une des deux colonnes, recréez la procédure :

SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS ON
GO
ALTER maprocedure...

Si ça ne marche pas, essayez un CREATE au lieu de l’ALTER.

Maintenant, incluant Reporting Services. Dumping sur les rapports !
Microsoft SQL Server 2005 Express Edition with Advanced Services

Avec les outils toujours gratuits d’administration et de création de rapports :
Microsoft SQL Server 2005 Express Edition Toolkit

Un blabla écrit sur un newsgroup au sujet de FILLFACTOR :

Cela dépend de la fréquence de mises à jour de ta table. Si tu effectues principalement des lectures (comme dans une base type OLAP), tu peux remplir les pages d’index, les requêtes seront plus efficaces.
Si tu fais de nombreuses mises à jour (update des colonnes indexées, ou insert), tu peux laisser plus de place pour permettre aux nouvelles entrées de l’index de s’insérer dans les pages existantes, et éviter les split.

A moins d’avoir des index de taille importante, ce n’est pas un élément très significatif, selon mes expériences (d’aucuns ne seront peut-être pas d’accord avec ça). Pour optimiser tes index, pense d’abord à mettre les colonnes les plus sélectives, et les plus utilisées dans tes requêtes, d’abord. Et à créer des index de la plus petite taille possible.

Il y a deux notions :
- FILLFACTOR : le remplissage du dernier niveau de l’index (leaf node)
- PAD_INDEX : le remplissage des noeuds intermédiaires, selon le pourcentag indiqué avec FILLFACTOR

Personnellement, je n’ai jamais utilisé PAD_INDEX, ou senti le besoin de l’utiliser, mais peut-être suis-je léger… Si tu as une grande table avec beaucoup d’updates ou d’insert, qui se font sur un index qui va se trouver modifié à l’intérieur (par opposition à un index qui grandit de façon monotone, sur une colonne identity par exemple), peut-être peux-tu essayer le PAD_INDEX avec un FILLFACTOR à 50 ou 70.
En sachant que cela va diminuer les performances de lecture, puisque SQL Server aura à parcourir plus de pages d’index pour retrouver les mêmes informations.

Il faut aussi savoir que ce pourcentage n’est pas maintenu dynamiquement le long du remplissage de l’index. Il est valable à la création, et à la recréation de l’index.

Pour voir si tu es très atteint par les splits de pages d’index, tu as un compteur du performance manager :
SQL Server:Access Methods – > Pages splits/Sec

Quelques liens sur le sujet :
SQL Index performance audit
Tips on Rebuilding SQL Server Indexes

A savoir aussi qu’une commande DBCC non documentée paermet d’avoir des informations sur les niveaux d’un index : DBCC IND

Apparemment PromptSQL est racheté par Red-Gate, et est en download gratuit jusqu’en septembre.
C’est la version 2.

C’est un outil qui fait l’autocomplétion du code SQL et qui se colle sur Query Analyzer ou SSMS (et qq autres éditeurs comme UltraEdit et EditPlus)

http://www.red-gate.com/products/sql_prompt/index.htm, ou mieux, ici

J’utilise la version 1.5 toute la journée. Il y a quelques bugs énervants mais malgré ça c’est un outil très précieux qui fait gagner beaucoup de temps.

Par exemple, autocomplétion des JOIN basé sur la compréhension des clés étrangères ou, pour les paresseux de l’intgrité référentielle, sur le nom des colonnes.