TITLE: Microsoft SQL Server 2017 Setup
------------------------------

The following error has occurred:

VS Shell installation has failed with exit code 1638.

declare @cpufactor int declare @iofactor int declare @durationfactor int /* parameter sniffing will usually lead to large CPU, IO and Duration increases. checking duration only might fail to distinguish it from blocking problems*/ set @cpufactor=100 /* 0 disables*/ set @iofactor=100 /* 0 disables*/ set @durationfactor = 100 /* 0 disables*/ select SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(ST.text) ELSE QS.statement_end_offset END - QS.statement_start_offset)/2) + 1) AS statement_text , ST.text as 'full batch', query_hash, query_plan_hash, * from sys.dm_exec_query_stats AS QS CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST where /*'strictly smaller than' will rule out any 0 values from resultset*/ @cpufactor * min_worker_time < max_worker_time and @iofactor * min_logical_reads < max_logical_reads and @durationfactor * min_elapsed_time < max_elapsed_time

https://www.microsoft.com/en-us/server-cloud/products/sql-server-2005/

Il existe plusieurs livres blancs et articles sur la migration de SQL Server mais peu d’entre eux évoquent le sujet tant redouté, … Service Broker !

SQL Server Service Broker (SSB) fournit la prise en charge native des applications de messagerie et de mise en file d'attente dans le Moteur de base de données. Construit autour des fonctions de base d'envoi et de réception de messages, il permet entre autres de traiter une file de traitement en asynchrone.

Exemples d’utilisation :

Bref, l’utilité de Service Broker n’est plus à démontrer. Il est d’ailleurs utilisé dans de nombreux produits Microsoft comme SCCM, SharePoint, MDS, ...

Dans cet article, j’évoquerai pourquoi il est important de suivre le cycle de supportabilité des versions de SQL Server, je présenterai les nouveautés du service au fil des versions. Pour finir nous verrons les difficultés de la migration du service à travers un exemple concret : La migration d’une base de données SQL Server 2005 à SQL Server 2014 et reprise de la communication Service Broker à partir d’une base de données SQL Server 2016.

Remarque : Dans la suite de l’article j’utiliserai les abréviations suivantes.

1 - Actualisation

La fin de support se réfère à la date à laquelle Microsoft ne fournit plus de corrections, de mise à jour ou encore d’assistances techniques en ligne. Il est donc plus que risqué de ne pas tenir compte de la supportabilité des versions.

Microsoft Support Life Cycle de SQL Server :

La politique d’actualisation de SQL Server a été mi-à jour récemment, il est dorénavant fortement conseillé d’installer les CUs au même titre que les SP : Announcing updates to the SQL Server Incremental Servicing Model (ISM).

Il existe deux stratégies principales pour la mise à niveau :

Remarque : Je ne présenterai pas les inconvénients, avantages des deux modes d’upgrade dans cet article.

2 – Service Broker : Présentation

SQL Server Service Broker (SSB) a été introduit avec SQL Server 2005, et permet d’envoyer et de recevoir des messages afin de déporter leurs traitements dans une application tierce ou sur une autre base de données d’une même instance ou d’une instance distante.

Un Service Broker se compose des quatre objets suivants :

1. Le type de message : En anglais « Message types », définit le type de données que contient un message (Empty, None, Valid_XML, Well_Formed_XML).

CREATE MESSAGE TYPE SenderMessageType VALIDATION=NONE
CREATE Message TYPE ReceiverMessageType VALIDATION=NONE

2. Un contrat : En anglais « Contracts », definit les types de messages d’un service Service Broker. C’est un accord entre deux services Service Broker (Un contrat par base de données qui participe à une conversation).

CREATE Contract SampleContract (
SenderMessageType SENT BY INITIATOR,
ReceiverMessageType SENT BY TARGET
)

3. Une queue : En anglais « Queue », est une file d’attente pour les messages reçus. Lorsque Service Broker reçoit un message, il l’insère dans la file d’attente associée au service cible après l’avoir validé.

CREATE Queue InitiatorQueue WITH status = ON

4. Un programme de service : En anglais « Service program », traite les messages entrants à partir d’une file d’attente.

CREATE Service SenderService ON QUEUE InitiatorQueue (SampleContract)

5. Une route, un itinéraire : En anglais « Route », spécifie le réseau sur lequel l'adresse d'un service Service Broker est située.

CREATE Route RouteA WITH
SERVICE_NAME = 'ReceiverService',
-- BROKER_INSTANCE = 'F6186F80-7DDA-4A7D-B08A-9931A02379D4',
ADDRESS = 'TCP://WIN-ADINKEGG0ER:4022'
GO

Dans la Route ci-dessus, ReceiverService est le service cible du serveur B. Si on ne spécifie par de « BROKER_INSTANCE » alors le service avec un nom similaire sera choisi au hasard par le serveur. Il est donc préférable de spécifier le « service_broker_guid » de la base de données cible (Depuis le serveur B SELECT service_broker_guid FROM sys.databases WHERE name = 'DatabaseA').

Voici les différentes étapes d’un dialogue :

De l'initiation d'un dialogue a la réception en passant par les ou les accusés de réception...

3 – Service Broker : Sécurité

Service Broker fournit deux types de sécurité, la compréhension de ces deux types de sécurité et la façon dont ils travaillent ensemble est primordiale pour concevoir, déployer et administrer des applications Service Broker :

Pour mettre en place la sûreté du transport, depuis la base de données « Master » :

USE master
GO

-- 1. Create a master key for master database.
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Romain.Casteres_PulsWeb.fr'
GO

-- 2. Create certificate and End Point that support certificate based authentication 
CREATE Certificate EndPointCertificateA
WITH Subject = 'A.Server.Local',
    START_DATE = '01/01/2006',
    EXPIRY_DATE = '01/01/2018'
    ACTIVE FOR BEGIN_DIALOG = ON;
GO

-- 3. Take a backup of the certificate created and install it into the remote instance by physically copying this certificate to Other Server.
BACKUP CERTIFICATE EndPointCertificateA TO FILE = 'C:\temp\EndPointCertificateA.cer';
GO

-- 4. Create certificate from the certificate backup file copied from the other server.
CREATE CERTIFICATE EndPointCertificateB From FILE = 'C:\temp\EndPointCertificateB.cer';
GO

-- 5. Create login from the certificate in remote server in the current server.
CREATE LOGIN sbLogin FROM CERTIFICATE EndPointCertificateB;
GO

-- 6. Grant the login, connect permissions on the end point.
GRANT CONNECT ON ENDPOINT::ServiceBrokerEndPoint To sbLogin
GO

Pour mettre en place la sûreté du dialogue, depuis la base de données « DatabaseA » :

Use DatabaseA
GO

-- 1. Create a master key for master DatabaseA.
CREATE Master Key Encryption BY Password = 'Romain.Casteres@PulsWeb.fr'
GO

-- 2. Create a user certificate. 
CREATE Certificate UserCertificateA
 WITH Subject = 'A.Server.Local',
    START_DATE = '01/01/2006',
    EXPIRY_DATE = '01/01/2018'
    ACTIVE FOR BEGIN_DIALOG = ON;
GO

-- 3. Take a backup of the user certificate created and install it into the remote instance.
BACKUP CERTIFICATE UserCertificateA TO FILE='C:\temp\UserCertificateA.cer';
GO

-- 4. Create a user with the same name as the user who has access rights on the other Database.
CREATE User UserB WITHOUT LOGIN
GO

-- 5. Create a user certificate from the user certificate backup file copied from the other server, with authorization to the user created in Step 4.
CREATE CERTIFICATE UserCertificateB 
	AUTHORIZATION UserB
	FROM FILE = 'C:\temp\UserCertificateB.cer';
GO

-- 6. Grant connect permissions to the user.
GRANT CONNECT TO UserB;

-- 7. Grant send permissions to the user on the local service.
GRANT SEND ON SERVICE::SenderService To UserB;
GO

-- 8)Create a Remote Service Binding with the user created.
CREATE REMOTE SERVICE BINDING ServiceBindingB TO SERVICE 'ReceiverService' WITH USER = UserB

Remarques : Si communication entre deux bases de données d'une même instance la sécurité du transport n'est pas nécessaire.

3 – Service Broker : Nouveautés

Voici les nouveautés du Service Broker par versions de SQL Server :

4 – Service Broker : Upgrade Démo

Voici le scénario de la démonstration : La base de données « DatabaseB » du serveur B situé dans l’instance SQL Server 2005 doit être migrée sur une autre instance SQL Server 2014 du serveur C. Après la migration, le serveur A doit pouvoir communiquer avec la base de données restaurée.

Définitions des différentes étapes :

4.1 - Initialisation

Étapes pour créer une application Service Broker Distribué :

1. Création des bases du Service Broker (messages types, contracts, services, queues).

2. Création du Transport Security:

3. Set up Dialog Security:

Certaines étapes sont à effectuer sur les deux serveurs.

4. Send Messages & Receive Messages

Voici les deux scripts T-SQL pour initier l’architecture : Lien.

4.2 – Backup & Restore

Après avoir finalisé toutes les discussions en cours, effectuer un backup de la base de données DatabaseB :

SELECT * FROM sys.transmission_queue
SELECT * FROM sys.conversation_endpoints

ALTER DATABASE DatabaseB SET DISABLE_BROKER WITH ROLLBACK IMMEDIATE;
	
BACKUP DATABASE [DatabaseB] TO  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\DatabaseB.bak' WITH NOFORMAT, NOINIT,  NAME = N'DatabaseB-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10

Sur l’instance cible, le serveur C sous SQL Server 2014 :

USE [master]
GO

RESTORE DATABASE [DatabaseB] FROM  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Backup\DatabaseB.bak' WITH  FILE = 2,  MOVE N'DatabaseB' TO N'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\DatabaseB.mdf',  MOVE N'DatabaseB_log' TO N'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\DatabaseB_log.LDF',  NOUNLOAD,  STATS = 5

Remarques :

SELECT service_broker_guid FROM sys.databases WHERE name = 'DatabaseB'

4.3 - Transportation Security

Pour reconfigurer le Transportation Security, il faut :

- Sur l’instance A :

ALTER DATABASE DatabaseA SET DISABLE_BROKER WITH ROLLBACK IMMEDIATE;
ALTER ROUTE RouteA WITH ADDRESS = 'TCP://192.168.0.39:4022';
ALTER DATABASE DatabaseA SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE;

USE [master];
GO

DROP LOGIN sbLogin
DROP CERTIFICATE EndPointCertificateB

CREATE CERTIFICATE EndPointCertificateB From FILE = 'C:\temp\EndPointCertificateB.cer';
GO

CREATE LOGIN sbLogin FROM CERTIFICATE EndPointCertificateB;
GO

GRANT CONNECT ON ENDPOINT::ServiceBrokerEndPoint To sbLogin
GO

- Sur l’instance B :

USE [master];
GO

Create Certificate EndPointCertificateB
WITH Subject = 'B.Server.Local',
START_DATE = '01/01/2006',
EXPIRY_DATE = '01/01/2018'
ACTIVE FOR BEGIN_DIALOG = ON;
GO

CREATE ENDPOINT ServiceBrokerEndPoint
STATE=STARTED
AS TCP (LISTENER_PORT = 4022)
FOR SERVICE_BROKER (
AUTHENTICATION = CERTIFICATE EndPointCertificateB,
ENCRYPTION =DISABLED
);

BACKUP CERTIFICATE EndPointCertificateB TO FILE = 'C:\Temp\EndPointCertificateB.cer'

CREATE CERTIFICATE EndPointCertificateA FROM FILE = 'C:\Temp\EndPointCertificateA.cer';
GO

CREATE LOGIN sbLogin FROM CERTIFICATE EndPointCertificateA;
GO

GRANT CONNECT ON ENDPOINT::ServiceBrokerEndPoint To sbLogin
GO

SELECT * FROM sys.certificates;
SELECT * FROM sys.services;
SELECT * FROM sys.endpoints;

Remarque : Pour une restauration de la base de données sur une même instance, la Transportation Security n’est pas à actualiser. Seul le Dialog Security est à reconfigurer.

4.4 - Dialog Security

Lors de la restauration d’une base de données le service broker de celle-ci est désactivé. Pour le réactiver :

ALTER DATABASE DatabaseB SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE;

Pour réencrypter les certificats avec la Master Key de la nouvelle instance :

USE DatabaseB
GO

OPEN MASTER KEY DECRYPTION BY PASSWORD = '45Gme*3^&fwu';
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;
CLOSE MASTER KEY;

4.5 - Test

Voici un script de test permettant d’envoyer un message et de le recevoir.

Depuis l’instance A :

-- Send Messages
DECLARE @InitDlgHandle UNIQUEIDENTIFIER;
DECLARE @RequestMsg NVARCHAR(100);
BEGIN TRANSACTION;
BEGIN DIALOG @InitDlgHandle FROM SERVICE SenderService TO SERVICE 'ReceiverService' ON CONTRACT SampleContract WITH ENCRYPTION = OFF;
SELECT @RequestMsg = N'Message for Target service.';
SEND ON CONVERSATION @InitDlgHandle MESSAGE TYPE SenderMessageType (@RequestMsg);
SELECT @RequestMsg AS SentRequestMsg;
COMMIT TRANSACTION;
GO

-- Receive Response
DECLARE @RecvReplyMsg NVARCHAR(100);
DECLARE @RecvReplyDlgHandle UNIQUEIDENTIFIER;
BEGIN TRANSACTION;
WAITFOR
( RECEIVE TOP(1)
    @RecvReplyDlgHandle = conversation_handle,
    @RecvReplyMsg = message_body
  FROM InitiatorQueue
), TIMEOUT 1000;
END CONVERSATION @RecvReplyDlgHandle;
SELECT @RecvReplyMsg AS ReceivedReplyMsg;
COMMIT TRANSACTION;
GO

SELECT * FROM sys.transmission_queue
SELECT * FROM sys.conversation_endpoints

Depuis l’instance B :

-- Send Response
DECLARE @RecvReqDlgHandle UNIQUEIDENTIFIER;
DECLARE @RecvReqMsg NVARCHAR(max);
DECLARE @RecvReqMsgName sysname;
BEGIN TRANSACTION;
Print 'Started Receiving ';
WAITFOR
( RECEIVE TOP(1)
    @RecvReqDlgHandle = conversation_handle,
    @RecvReqMsg = message_body,
    @RecvReqMsgName = message_type_name
  FROM TargetQueue
), TIMEOUT 1000;
SELECT @RecvReqMsg AS ReceivedRequestMsg;
IF @RecvReqMsgName = 'SenderMessageType'
BEGIN
     DECLARE @ReplyMsg NVARCHAR(100);
     SELECT @ReplyMsg = N'Message is received';
     SEND ON CONVERSATION @RecvReqDlgHandle MESSAGE TYPE ReceiverMessageType (@ReplyMsg);
     END CONVERSATION @RecvReqDlgHandle;
END
SELECT @ReplyMsg AS SentReplyMsg;
COMMIT TRANSACTION;
GO

SELECT * FROM sys.transmission_queue
SELECT * FROM sys.conversation_endpoints

5 – Troobleshooting

Et parce que rien n’est toujours aussi simple que dans un article… Voici quelques outils pour le Troubleshooting :

ssbdiagnose -E CONFIGURATION FROM SERVICE SenderService -S ROMAINCA -d DatabaseA TO SERVICE ReceiverService -S 192.168.0.39 -d ECHO ON CONTRACT SampleContract

EXEC xp_ReadErrorLog 0, 1, NULL, NULL, NULL, NULL, 'DESC'

USE master
GO
ALTER ENDPOINT ServiceBrokerEndPoint STATE = STOPPED;
GO
ALTER ENDPOINT ServiceBrokerEndPoint STATE = STARTED;
GO

declare @conversation uniqueidentifier
while exists (select 1 from sys.transmission_queue )
begin
	set @conversation = (select top 1 conversation_handle from sys.transmission_queue )
	end conversation @conversation with cleanup
end

declare @conversationHandle uniqueidentifier
select top 1 @conversationHandle = conversation_handle from sys.conversation_endpoints
while @@rowcount = 1
begin
     end conversation @conversationHandle with cleanup
     select top 1 @conversationHandle = conversation_handle from sys.conversation_endpoints
end 

6 – Conclusion

En conclusion, Service Broker permet de créer une couche asynchrone pour vos applications et/ou permet de déporter le traitement de données dans une autre application. La migration du service peut s’avérer compliquée, mais elle ne doit pas être un frein à l’évolution de version de vos plateformes. En respectant certaines étapes listées dans cet article, vos migrations « devraient » bien se passer !

Voici quelques liens et ressources complémentaires :

Je tiens à remercier Nicolas Soukoff (PFE SQL Server), Olivier Aupetit (Support Escalade Eng.) et Sarah Bessard (DBA chez DCube) pour leurs aides sur le sujet. Merci à Érik Delepeleire (PFE SQL Server) pour la relecture de cet article.

Romain Casteres

Premier Field Engineer – SQL & BI & Big Data 

Today we’ll look at a the ListenAll settings of the SQL Server server-side protocol.

When active, this setting will have SQL Server bind all available  IPs of the server, and use the same listening port for all of them.

Disabling ListenAll allows to manually select which IPs the SQL Server instance will bind, and also change the listening port for each those IPs.

For exemple, using the following settings (I used the loopback adapter as it was readily available)

Will lead to :

 Notice the different ports for the loopback adapter and the main IP.

However, using this option has a side consequence. You will notice that after you disable ListenAll, the errorlog will show that SQL Server no longer autoregisters the TCP SPN for the instance.

With ListenAll active : 

 The first SPN is named pipe based, and the second one with the port is the TCP one.

(Of course, this is provided the SQL Service account has the required privileges to register SPN in the first place)

With Listen All disabled :

 Only the NamedPipes SPN is auto registered.

Why ?

Well the short answer is that his is by design, and that the code behaves as it is expected to.

But if we look at it more in details, it makes sense.

When using the listenall option, there will be a single TCP port for all the IP that are bound by SQL. Registering the TCP SPN –which includes the port - is therefore straightforward. Just use the listenall port !

But if listenall is disabled, that means that each IP may have a different TCP port. It becomes clear why a single port-based TCP SPN registration is not possible anymore : which port value to select ?

Now there is the scenario where the listenall option is disabled to avoid that SQL Server binds all IP, yet all the individual IPs enabled for SQL still use the same manual value for the port. In that case the SPN auto registration would be possible, but this would need some sizeable added logic within SQL Server to detect this situation.

The decision was thus made to only do TCP SPN autoregistration when listenall is active. Any other situation will require the DBA to manage the TCP SPN registration manually.

Hope that helps !

Guillaume Fourrat

Escalation Engineer

Microsoft France

L’objet de cet article est de vous fournir un certain nombre de requêtes vous permettant de générer une documentation sur vos projets Reporting Services.

L’idée de cet article m’est venue en analysant les N rapports d’un projet. Voici les quelques problématiques auxquelles j'ai été confrontées : Retrouver les liens morts entre les différents rapports, documenter la solution et simplifier les déploiements ainsi que la configuration des rapports.

1 - Introduction

A l’installation de Reporting Services, deux bases de données sont installées ReportServer et ReportServerTempDB.

La base de données ReportServer stocke le contenu suivant :

• Les objets gérés par le serveur comme les rapports, les rapports liés, les sources de données, les modèles de rapports, les dossiers … ainsi que toutes les propriétés et les paramètres de sécurité associés à ces éléments.
• Les définitions des souscriptions et leurs planifications.
• Les Snapchots et l’historique des rapports
• Les propriétés du système et les paramètres de sécurité
• Les logs d’exécution
• Les clés symétriques et connexions cryptées ainsi que les références des sources de données

La base de données ReportServerTempDB quant à elle gère les données temporaires liées aux sessions, au cache des données, les tables de travail temporaires. Un processus automatique s’occupe de supprimer les anciens éléments inutilisés de cette base.

Afin de documenter l’environnement SSRS, sa configuration, les différents rapports publiés ainsi que les souscriptions nous effectuerons des requiêtes sur les différentes tables de la base ReportServer.

2 - Informations sur l’instance SSRS

2.1 - Informations sur l’instance

Remarque : La table Keys contient aussi les informations sur les clés de chiffrement et sur l’installation de l’instance.

2.2 - Informations sur la configuration de l’instance

Résultat :

Voici la liste des différents paramètres : https://msdn.microsoft.com/en-us/library/bb934303.aspx 

2.3 - Informations sur les utilisateurs et leurs rôles

Résultat :

2.4 – Informations sur l’utilisation du cache

2.5 – Informations sur les souscriptions et leurs planifications

3 - Informations sur les rapports

3.1 - Liste des rapports et leurs paramètres

Résultat :

Remarques :

• Le champ XMLRdl affiche l’ensemble du .RDL au format XML
• Le champ Path détermine l’emplacement du rapport par rapport au dossier racine
• Le champ Hidden détermine si le rapport sera caché ou non dans la liste des objets dans Report manager

En effet il est possible de cacher à l’utilisateur des objets dans Report manager :

3.2 – Liens morts entre les rapports

Une problématique récurrente à SSRS : « J’ai une centaine de rapports dans mon projet, certains rapports ont changés de noms, … Comment retrouver les liens morts entre les différents rapports ? »

Voici la solution :

Résultat :

Remarques : Ici le rapport « Product Line Sales » contient un lien (NbLinks) vers le rapport « Employee Sales Summary SQL2008R2 » situé dans le dossier « /AdventureWorks Sample Reports/ » qui n’existe pas ou plus.

L’Addin Excel NodeXL (Excel 2007 à 2016) n’est plus à présenter, il permet d’analyser sous forme de graph tout type de données. (Mon article de présentation de NodeXL : https://www.pulsweb.fr/nodexl/).

Voici le résultat d’une analyse sur une partie des rapports d’un projet SSRS :

Analyse :

• Vertex 1 correspond au rapport contenant le lien vers le rapport Vertex 2
• La grosseur du lien correspond au nombre de liens présents dans le rapport. Exemple le rapport « CM-Main » contient 8 liens vers le rapport « CM-Dashboard Hierarchy all Levels – Summary ».
• La direction de la flèche indique le lien entre les rapports. Exemple le rapport « CM-main » contient un lien vers le rapport « CM-Dashboard SQL » et vice versa.
• Le format de la flèche en continue ou en pointillé dépend de l’existence du rapport. Exemple le rapport « CM-Main » contient un lien vers le rapport « CM-Bad » or celui-ci n’existe pas.

Combiner le résultat de la précédente requête avec NodeXL permet d’avoir une vision complète des relations entre les différents rapports d’un projet, de vérifier qu’il n’y a pas de rapport isolé (sans aucun lien allant vers celui-ci), d’analyser les liens morts, …

3.3 – Informations sur les paramètres d’un rapport

Résultat :

3.4 - Liste des Data Sources et leurs rapports

Résultat :

3.5 - Liste des sous rapports

4 – Analyse des Logs

A partir de SQL Server 2008 R2, la vue ExecutionLog3 permet d’avoir des informations concernant l’utilisation des rapports SSRS.

Résultat :

Plus d’informations sur la vue ExecutionLog3 : https://msdn.microsoft.com/en-us/library/ms159110(v=sql.105).aspx

5 – Déploiement

Il existe plusieurs solutions pour déployer des rapports SSRS : SSDT (BIDS auparavant), Report Manager ou encore l’utilitaire RS.exe.

Lorsque plusieurs rapports sont à déployer, SSDT est bien pratique, mais celui-ci n’est pas toujours installé sur l’environnement cible ou un environnement ayant accès à l’environnement cible. Report Manager quant à lui ne permet pas l’Upload de plusieurs rapports en une fois ! La solution est alors d’utiliser RS.exe.

Le script RSS suivant permet d’uploader les rapports d’un dossier local : OneDrive

Après avoir téléchargé le .RSS, il faut créer et modifier le .Bat :

Le script RSS a été réalisé par Nishar, plus d’informations sur celui-ci à l’adresse suivante : SSRS Deployment–Complete Automation–2012 & 2008.

6 – Conclusion

Dans cet article nous avons vu quelques requêtes T-SQL permettant de documenter une instance Reporting Services, ses rapports et sa configuration.

Nous avons aussi vu une requête basique permettant d’auditer l’utilisation des rapports, leurs temps d’exécution …

Enfin le script de déploiement présenté permet de gagner du temps sur l’Upload d’une solution.

Sans oublier le fait qu’avec quelques requêtes T-SQL et NodeXL, il est possible d’avoir une vision complète sur les différents liens entre les rapports SSRS !

Romain Casteres

Premier Field Engineer – SQL & BI & Big Data 

Les versions récentes de SQL Server offrent la possibilité d'introduire des notions de Qualité de Service vis à vis de certaines ressources : IO, RAM, CPU, par la fonctionnalité 'Resource Governor'.

La création d'un algorithme gérant l'allocation ou non de ces ressources n'est pas aussi triviale qu'il n'y parait (je vous laisse découvrir son petit monde de complexité sur le Web).

Dans le contexte de SQL Server, cet algorithme doit de plus s'intégrer au contexte du scheduling coopératif qui préside à l'exécution des worker threads : en gros l'algoritme ne peut pas se contenter d'interrompre tout SPID qui a dépassé son quota car il n'est pas pré-emptif. Au lieu de ça, il agit à des 'checkpoints' et doit décider à ce moment si le thread peut continuer ou pas sur la base d'une estimation de sa consommation future en ressource pendant le prochain cycle (jusqu'au prochain checkpoint, qui est décidé par le code qu'exécute le thread et non pas par l'algorithme, qui de plus n'a aucune visibilité sur cette échéance). Multiplions ça par n threads travaillant dans plusieurs groupes différents avec des quotas hauts et bas différents. Tout de suite moins simple, n'est-ce-pas ? :)

Sans rentrer plus dans les détails, le fait est que les algorithmes implémentés vont 'tendre' vers les valeurs cibles configurées par le DBA dans le resource governor. Cependant ils pourront d'autant plus s'en rapprocher qu'ils brasseront une quantité importante de SPID à activités variées. Si très peu de SPID sont actifs à un instant t, il y a des chances qu'il soit impossible d'obtenir la granularité qui permette de s'approcher de manière fiable des valeurs cibles.

Un peu comme si vous deviez remplir un car de 50 places sans pouvoir séparer les groupes de passagers :  c'est plus facile en travaillant avec de nombreuses familles de tailles diverses qu'avec 3 ou 4 colonies de vacances complètes.

Cet élément établi, revenons dans le contexte d'un DBA découvrant cette fonctionnalité. Son premier reflexe sera de la tester afin de voir si elle répond à ses besoins. Et ce test consistera très certainement a créer 2 groupes, puis un SPID dans chacun ayant une activité lourde vis à vis de la ressource arbitrée. Et donc de prendre complètement à revers l'algorithme :) Vous ne serez donc pas étonnés si je vous dis que les résultats d'un tel test risquent d'être décevants, avec des groupes de ressources ne se conformant pas aux limites mises en place. Avec un peu de malchance une des activités fera un usage artificiellement poussé de fonctions intensives qui rendent plus rarement la main au scheduleur que le SPID lambda, ce qui scellera le verdict.

Donc, amis DBA, si vous décidiez d'explorer le Resource Governor de SQL Server, évitez les colonies de vacances et assurez-vous de créer un jeu de test représentatif d'un serveur actif, c'est à dire comprenant un nombre conséquent de SPID associés à des tâches variées, ce qui donnera aux algorithmes assez de matériau pour produire un comportement conforme à vos attentes.

A bientôt,

Guillaume Fourrat

Ingénieur d'Escalade

Microsoft France

I had recently to understand why a SQL Server had repeated occurences of "SetFileIoOverlappedRange failed, GetLastError is 1314" in its errorlog.

Because the web lookup of the main keyword would likely lead to https://support2.microsoft.com/kb/2679255/en-us, that (rightfully) would make the DBA worried about what could possibly be happening on the Server.

Because Os error 1314 is ERROR_PRIVILEGE_NOT_HELD, other research would also lead to double checking SeLockMemoryPrivilege  as specified in https://msdn.microsoft.com/en-us/library/windows/desktop/aa365540(v=vs.85).aspx, only to find out that the privilege is set for SQL Server Service Account (telltale item is the entry 'Using locked pages in the memory manager.' in startup section of errorlog).

Finally, testing would show that attaching a Database would generate three of those messages at every try :

2014-10-13 17:24:09.48 spid53      SetFileIoOverlappedRange failed, GetLastError is 1314
2014-10-13 17:24:09.54 spid53      Starting up database 'dummy'.
2014-10-13 17:24:09.55 spid53      SetFileIoOverlappedRange failed, GetLastError is 1314
2014-10-13 17:24:09.55 spid53      SetFileIoOverlappedRange failed, GetLastError is 1314

So what have we got here ?

Well the thing is, during the attach operations, some part of the file operations will be done under the client's security context.

But if SQL Server was started with SeLockMemoryPrivilege, then it would attempt to generate IOs that use SetFileIoOverlappedRange API, including the IOs that take place under the client's context during special 'attach' code.

If the Client's account does NOT have SeLockMemoryPrivilege enabled, then the attempt by SQL to use the API would fail and generate the messages previously described in the Errorlog.

Conversely :

• If SQL Server account doesn't have SeLockMemoryPrivilege, then the situation is avoided.
• If both SQL Server Account and the Client's (user) interactive account have SeLockMemoryPrivilege, then the situation is avoided too.
• note that this would likely require to start SSMS 'as administrator'. Failing that, the message will appear
• also note that enabling the privilege requires a log out/log in to activate.

So the main thing to remember is that this error message in this context (attach DB) can safely be ignored and is not related to the scribbler issues described in https://support2.microsoft.com/kb/2679255/en-us,

The only possible consequence can be a de-activation of SetFileIoOverlappedRange API for the DB until the SQL Service is restarted. This should have a very limited impact, and can be easily mitigated by restarting the DB (put it offline and online again) right after an attach.

Hope this helps removing a bit of confusion on the topic :)

Regards,

Guillaume Fourrat

Escalation Engineer

Microsoft France

 Les statistiques sont utilisées par l'optimiseur pour évaluer la sélectivité des expressions, et donc la taille des résultats intermédiaires et finaux.

Elles peuvent être:

• Crées automatiquement ou manuellement.
• Mises à jour automatiquement ou manuellement.
• Mises à jour en synchrone ou en asynchrone
• Basées sur un échantillonnage de valeurs ou toutes les valeurs

Le plus elles sont à jour, le meilleur c’est. Il faut donc s’appuyer sur la mise à jour automatique ou les faire manuellement. La mise à jour automatique est déclenchée quand au moins 500 + 20% des données de la table ont évoluées.

Problème sur les grosses tables

Pour une tables avec des millions de lignes, il peut prendre des jours voir des mois avant d’atteindre le seuil de 20%.

Si une nouvelle partition est ajoutée à la table et que ça ne modifie pas 20% du total de celle-ci, les statistiques ne sont pas mises à jour et il n’y a pas d’information sur cette nouvelle partition.

Une mise à jour manuelle des statistiques peut être déclenché mais elle va échantillonner toute la table ce qui peut être trop long.

Les Statistiques Incrémentales de SQL 2014

Objectif:

• Mise à jour plus rapide sur des tables avec de larges partitions
• Des mises à jour automatiques plus fréquentes
   

Les statistiques incrémentales ne sont disponible que pour tables partitionnées. Une page de statistique est créée par partition, puis un merge est effectué en chaque pages deux a deux jusqu’à la page globale de la table. L’ensemble des pages sont persistante sur disque. Lors de l’ajout d’une partition une nouvelle branche est créée.

La mise à jour automatique se déclenche avec un nouveau seuil:

• 500 + 20% de la taille moyenne des partitions en ne prenant en compte que les partitions non vides et en enlevant la plus petite et la plus grosse.
• Seules les partitions avec 20% de modification sont mises à jour.

Prenons un exemple :

• Une table avec 6 partitions, 10000 rows

• L’ancien seuil de mise à jour est : 500 + 20% * 10000 = 2500

• Auto Stat avec 900 enregistrements modifiés :
  • Le nouveau seuil est :
    • Moyenne des partitions non vide en éliminant la plus petite et la plus grande : (2000 + 2000 + 2000) /3 = 2000
    • Seuil : 500 + 20% * 2000 = 900

   

  • Les partitions mises à jour :
    • Partition 2 = 2000*20% = 400 (autostat)
    • Partition 4 = 1000*20% = 200 (autostat)
    • Partition 5 = 3000*20% = 600 (no autostat)

 Script:

Increment_Stats.sql

Bonjour à tous,

J'ai récemment eu à me pencher sur le détail de l'implémentation de la gestion de l'encodage Unicode UTF16 dans SQL Server.

La documentation existante (Microsoft ou tierce partie, avec un bon point de départ ici : https://www.unicode.org/standard/principles.html)  est plus que complète, le but est ici d'avoir un exemple simple, facile à déployer, et qui permet de se confronter aux mécanismes en jeu sur notre SGBD préféré.

NB :  L'utilisation de caractères Unicode avancés met par contre à mal la (rustique) chaine de publication de ce blog, j'utiliserai donc des captures d'écrans des requêtes et résultats, et j'attacherai le script au blog.

Création du kit de test :

 (Ce site a été pratique pour recueillir du texte 'exotique' : https://www.i18nguy.com/unicode/plane1-utf-16.html )

 Notre script insert donc des données unicode ‘avancées’ dans deux tables SQL distinctes :

·         La table ‘t_nosc’ qui utilise une collation 'classique'

·         La table ‘t’ utilisant les nouvelles collations 'surrogate chars'  apportées par SQL Server 2012 (comme décrit ici https://msdn.microsoft.com/en-us/library/ms143726(v=sql.110).aspx )

 On remarquera au passage que Management Studio (l’application cliente utilisée pour les tests) et plus généralement l’environnement Windows a dans mon cas très bien géré le copier/coller depuis le site précité ouvert dans Internet Explorer vers une fenêtre de requête SSMS : les valeurs unicodes ont bien été récupérées et SSMS a affiché les caractères spéciaux sans action particulière. Dans ce contexte il faut vraiment garder à l’esprit que l’affichage du caractère (et donc l’existence d’une représentation graphique pertinente) et son stockage sont distinct. Si votre client ne sait pas afficher un caractère donné, vous aurez droit aux points d’interrogation ou aux carrés blancs typiques, mais cela n’implique pas obligatoirement que les données unicodes sont invalides. Le script SQL est attaché à cet article, je vous invite à utiliser SSMS pour l'ouvrir.

Le SELECT vient ensuite requêter les données fraichement insérées, en y ajoutant quelques appels à des fonctions de chaines usuelles (LEN, SUBSTRING), et récupère différents niveaux d’encodage de la chaine : le ‘codepoint’ unicode, et le flux binaire ‘brut’.

Voici les résultats sur les deux tables :

Table sans collation SC :

Table avec collation SC :

Voyons ce que cela nous permet de conclure :

·         La 1ère colonne nous montre que nous récupérons bien les chaines d’origine dans les deux cas ! Pas de caractère invalide ou mal interprété. Or nous savons que les caractères choisis ont un encodage UTF16, SQL Server est donc capable de stocker et de restituer des chaines UTF16 nativement, sans besoin d’utiliser des collations particulières ! Il faut bien sûr utiliser des types de colonnes unicode …

·         La  2^ème colonne permet par contre de constater que les fonctions de manipulations de chaine sont impactées par nos caractères ‘exotiques’ UTF16 : par exemple la ligne 3 nous indique 10 caractères de long dans le premier cas, car SQL Server voit 5 fois 2 caractères UCS2 (2 octets) alors que la collation SC gère correctement les 4 octets par caractères et affiche comme longueur 5. Cet aspect est attendu et documenté (cf fin de https://msdn.microsoft.com/en-us/library/ms143726.aspx)

·         De la même manière, la 3^ème colonne / ligne 3 ne donne qu’un seul caractère alors que la demande est un SUBSTRING de deux caractères de long. Cette opération illustre bien comment SQL Server peut par défaut permettre à ses clients full UTF16 de fonctionner parfaitement sans être capable de ‘comprendre’ l’UTF16 lui-même : SQL Server croit émettre 2 caractères distincts, et le client détecte que ce sont 2 paires relatives au même caractère UTF16 à 4 octets, et les ‘réunit’ pour ne former qu’un seul caractère à l’affichage.

·         La 4ème colonne illustre le cas où un caractère à 4 octets (une surrogate pair) va être coupé en deux : la première table non-SC nous donne des caractères invalides, car une moitié (2octets) isolée de caractère à 4 octets n’a aucune signification. Et c’est en fait une bonne chose, car on pourrait imaginer que les 2 moitiés à 2 octets d’un caractère à 4 octet aient une autre signification possible quand elles sont isolées que quand elles sont groupées. Cela induirait un remplacement silencieux d’un caractère par deux autres (valides, mais non attendus) si d’aventure une ‘surrogate pair’ UTF16 était scindée et gérée comme deux caractères à 2 octets. Bien dangereux et insidieux non ? Comme nous le verrons plus bas, l’encodage UTF16 n’autorise pas cela, et nous avons donc quand une moitié de surrogate pair est traitée de manière isolée un caractère invalide permettant de détecter le problème. Dans le cas de la table avec SC, ce sont bien les 2 moitiés de la surrogate pair qui sont consommées pour nous fournir le caractère stocké.

·         Les  5^ème et 6^ème colonnes nous indiquent le ‘codepoint’ unicode de la colonne précédente. On note des valeurs ‘basses’ pour nos caractères latins habituels, associée au ‘Basic Multilingual Plane’ ou BMP, par contre les caractères exotiques sont associés à des valeurs élevées. Sur la table non SC, on voit la valeur 0xD800 (55296) répétée pour des caractères différents. Cela est lié au fait que SQL Server regarde une moitié seulement de la Surrogate Pair des caractères exotiques et cette moitié a la même valeur unicode pour les caractères du script d’exemple (la variabilité est sur la 2^ème paire, il est facile de la faire apparaitre en changeant l’offset du substring). On verra plus bas le pourquoi de cette valeur D800. La table « SC » par contre fait apparaitre des valeurs distinctes, et >65536 ou 0xFFFF, impliquant plus de 2 octets d’encodage.

·         La 6^ème  colonne fait apparaitre le flux binaire brut correspondant au stockage de la chaine unicode dans SQL Server. Un élément important est d’observer que pour les caractères du BMP (typiquement, nos caractères latins), l’encodage binaire et le codepoint unicode ont la même valeur (ex : 0x0061 pour le ‘a’). Cette colonne permet également de visualiser directement la taille d’encodage doublée pour nos chaines exotiques. Vous constaterez également que le flux binaire est strictement identique pour la table t_nosc et t : l’utilisation des collations SC ne modifie pas l’encodage, et à nouveau, on voit que SQL Server a bien stocké 4 octets par caractère même dans la collation par défaut. Enfin, on voit que les caractères exotiques ont visiblement un encodage qui n’est pas ‘juste’ le codepoint unicode, ce sera l’objet de notre exploration ci-dessous.

Nous allons maintenant nous intéresser à l’encodage d’un caractère UTF16 à 4 octets (donc une ‘surrogate pair’) dans SQL Server.

Notre cobaye sera le caractère de la ligne 5, que nous pouvons retrouver en tapant son codepoint 1031E  sur https://www.unicode.org/charts/charindex.html. Comment arriver de cette valeur à l’encodage binaire de la dernière colonne ?

https://www.unicode.org/faq/utf_bom.html#utf16-3 Nous indique un algorithme de conversion mais qui est peu lisible pour un humain, voyons les étapes successives :

·         Codepoint Unicode 0x0001031E

·         On retire 0x10000

o    0x0001031E - 0x10000 = 0x00031E

·         Traitement du 1^er élément de la surrogate pair (‘lead’ pair ou ‘high offset)

o    10 bits ‘hauts’ = Masque 0xFFC00

o    select convert(varbinary, convert(int,0x31E) & 0xFFC00)

o    = 0x00000000

o    Ajout de l’offset arbitraire des Lead surrogate : 0xD800

o    0x0 + 0xD800 = 0xD800

·         Traitement du 2^ème élément de la surrogate pair (‘trailing’ ou ‘low offset’)

o    10 bits ‘bas’ = Masque 0x003FF

o    select convert(varbinary, convert(int,0x31E) & 0x3FF)

o    = 0x0000031E

o    Ajout de l’offest arbitraire des Trailing Surrogate : 0xDC00

o    0x0000031E+0xDC00 = 0xDF1E

·         La surrogate pair est donc :

o    0xD800 0xDF1E

·         N’oublions pas la convention ‘little endian’ et appliquons le byteswap :

o    0x00D81EDF

·         Nous retrouvons bien l’encodage retourné par SQL Server !

Comme rapidement évoqué plus haut, les offsets arbitraires utilisés pour encoder la lead et trailing pair aboutissent à des valeurs d’encodage pour chaque paire qui sont réservées pour des surrogate pairs : si pour une raison donnée on se retrouve à considérer une seule moitié de la paire, sa valeur indique sans équivoque qu’elle est une moitié leading ou une trailing et qu’elle doit être nécessairement associée à sa ‘conjointe’ pour être décodée. Il ne peut pas y avoir de ‘mauvaise interprétation’ silencieuse d’une ‘demi paire’ UTF16 en tant que caractère codé sur 2 octets.

En pratique le ‘Basic Multilingual Plane’ a toutes les chances de contenir l’ensemble des caractères que vous stockerez dans SQL Server, et ces valeurs seront donc encodées directement sur 2 octets qui seront nativement gérés par SQL Server, sans autre réglage particulier que d’utiliser des types unicodes (nvarchar, nchar..). Quand bien même un caractère rare se glisserait dans votre flux de données, qui nécessiterait un encodage sur 4 octets, nous avons vu que SQL Server pourra le stocker et le restituer sans problème, toujours sans ‘réglage’ supplémentaire. Mais si vous prévoyez de faire des manipulations de chaines avancées au sein de SQL Server, et que des caractères UTF16 sur 4 octets sont prévus, alors dans ce cas l’utilisation des collations avancées de SQL Server 2012 semble pertinente.

A bientôt !

Guillaume Fourrat

Ingénieur d'Escalade

query.sql