Discussion :

[FMJ]

Bonjour,

J'utilise un SQL Server 2000 sur un Win2003. J'ai souhaité testé les prefs de mes bases sur un SQL Server 2008. J'ai donc installé la version SQL Server 2008 (RTM) - 10.0.1600.22 en version de démonstration et crée une nouvelle instance MSSQLSERVER2008, celle sous SQL Server 2000 restant en instance principale.

J'ai donc configuré le canal nommé suivant à la fois sur le serveur et sur le client via "SQL Server Configuration Manager" (la connexion se fait sur la même machine) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

\\.\pipe\MSSQLSERVER2008\sql\query

Impossible de se connecter (erreur n°2, etc.).

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (.Net SqlClient Data Provider)

Numéro de l'erreur*: 2
Gravité*: 20
État*: 0

J'ai fait X tests pour revenir à la config de base avec seulement les canaux nommés d'activé et avec pour chaîne "\\.\pipe\sql\query". Et là ça fonctionne ! D'ailleurs comment cela peut-il fonctionner alors que SQL Server 2000 soit sur le même canal. Parce qu'il s'agit de 2 versions différentes ?

Pour info, j'ai beau changé la chaîne du client : la connexion fonctionne quand même (je précise que "Mémoire partagée" et "TCP/IP" sont désactivés). Il faut juste que "canaux Nommés" soit activés sur le client avec n'importe quelle chaîne.
Et oui je redémarre bien à chaque fois le service SQL Server.

Comme je commençais à m'arracher les cheveux, je pose la question :

> Est-ce que c'est juste dû à mon incompétence.

> Est-ce dû au bridage de la version de démo

> Ou autre ?

Merci d'avance de votre aide.

[SQLpro]

1) oui, sans doute
2) non

Mais la question est : pourquoi utilisez vous les canaux nommées ? C'est quand même ce qu'il y a de plus has been !

A +

[dbaffaleuf]

Hello,

Recherche dans le fichier ERRORLOG de l'instance 2008 la chaîne 'Server local connection provider is ready to accept connection on ...', il doit te donner le nom du ou des canaux écoutés par ton instance. Le nom d'un pipe pour une instance nommée doit être préfixé de 'MSSQL$', si ton instance nommée est .\MSSQLSERVER2008, ton canal devrait s'appeler :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[ \\.\pipe\MSSQL$MSSQLSERVER2008\sql\query ]

Tu peux forcer le protocole à la connexion pour être sûr:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sqlcmd -E -Snp:'\\.\pipe\MSSQL$MSSQLSERVER2008\sql\query'

Le truc c'est que si tu ne fais qu'une connexion locale, SQL Server va privilégier de passer par LPC au niveau des protocoles (mémoire partagée), pour ne pas prendre une socket TCP ou NP alors qu'il n'en a pas besoin. Pour que tes tests soient valides, il faudrait les faire depuis un client distant. Pour savoir quel protocole est utilisé dans la connexion courante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select net_transport from sys.dm_exec_connections where session_id=@@spid

David B.

[FMJ]

1) oui, sans doute
2) non

Mais la question est : pourquoi utilisez vous les canaux nommées ? C'est quand même ce qu'il y a de plus has been !

A +

Bonjour Frédéric.

Quelle méthode préconises-tu ?

[FMJ]

Hello,

Recherche dans le fichier ERRORLOG de l'instance 2008 la chaîne 'Server local connection provider is ready to accept connection on ...', il doit te donner le nom du ou des canaux écoutés par ton instance. Le nom d'un pipe pour une instance nommée doit être préfixé de 'MSSQL$', si ton instance nommée est .\MSSQLSERVER2008, ton canal devrait s'appeler :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[ \\.\pipe\MSSQL$MSSQLSERVER2008\sql\query ]

Tu peux forcer le protocole à la connexion pour être sûr:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sqlcmd -E -Snp:'\\.\pipe\MSSQL$MSSQLSERVER2008\sql\query'

Le truc c'est que si tu ne fais qu'une connexion locale, SQL Server va privilégier de passer par LPC au niveau des protocoles (mémoire partagée), pour ne pas prendre une socket TCP ou NP alors qu'il n'en a pas besoin. Pour que tes tests soient valides, il faudrait les faire depuis un client distant. Pour savoir quel protocole est utilisé dans la connexion courante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select net_transport from sys.dm_exec_connections where session_id=@@spid

David B.

Bonjour David

J'a bien la séquence indiquée dans le ERROLOG. J'avais essayé avec "\\.\pipe\MSSQL$MSSQLSERVER2008\sql\query" avant d'enlever le MSSQL$, me disant que le $ posait peut-être problème.

Je vais tester sur une machine distante.

Par contre comment le LPC pourrait-il être prioritaire alors qu'il est désactivé dans la config de SQL native client 10.0 et sur celle de l'instance ?

[dbaffaleuf]

J'ai bien la séquence indiquée dans le ERROLOG.

Tu peux poster la ligne exacte de l'errorlog STP ?

Par contre comment le LPC pourrait-il être prioritaire alors qu'il est désactivé dans la config de SQL native client 10.0 et sur celle de l'instance ?

http://msdn.microsoft.com/en-us/libr...op8gr43e1f34d2

[FMJ]

Voici le ERRORLOG complet

2010-05-31 11:22:56.74 Server Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (Intel X86)
Jul 9 2008 14:43:34
Copyright (c) 1988-2008 Microsoft Corporation
Enterprise Evaluation Edition on Windows NT 5.2 <X86> (Build 3790: Service Pack 2)

2010-05-31 11:22:56.74 Server (c) 2005 Microsoft Corporation.
2010-05-31 11:22:56.74 Server All rights reserved.
2010-05-31 11:22:56.74 Server Server process ID is 1740.
2010-05-31 11:22:56.74 Server Authentication mode is MIXED.
2010-05-31 11:22:56.74 Server Logging SQL Server messages in file 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER2008\MSSQL\Log\ERRORLOG'.
2010-05-31 11:22:56.74 Server This instance of SQL Server last reported using a process ID of 1432 at 31/05/2010 11:22:48 (local) 31/05/2010 09:22:48 (UTC). This is an informational message only; no user action is required.
2010-05-31 11:22:56.74 Server Registry startup parameters:
-d C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER2008\MSSQL\DATA\master.mdf
-e C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER2008\MSSQL\Log\ERRORLOG
-l C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER2008\MSSQL\DATA\mastlog.ldf
2010-05-31 11:22:56.75 Serveur SQL Server is starting at normal priority base (=7). This is an informational message only. No user action is required.
2010-05-31 11:22:56.75 Serveur Detected 2 CPUs. This is an informational message; no user action is required.
2010-05-31 11:22:56.91 Serveur Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node. This is an informational message only. No user action is required.
2010-05-31 11:22:56.97 Serveur Node configuration: node 0: CPU mask: 0x00000003 Active CPU mask: 0x00000003. This message provides a description of the NUMA configuration for this computer. This is an informational message only. No user action is required.
2010-05-31 11:22:56.99 spid7s Starting up database 'master'.
2010-05-31 11:22:57.03 spid7s Recovery is writing a checkpoint in database 'master' (1). This is an informational message only. No user action is required.
2010-05-31 11:22:57.14 spid7s Resource governor reconfiguration succeeded.
2010-05-31 11:22:57.14 spid7s SQL Server Audit is starting the audits. This is an informational message. No user action is required.
2010-05-31 11:22:57.14 spid7s SQL Server Audit has started the audits. This is an informational message. No user action is required.
2010-05-31 11:22:57.16 spid7s FILESTREAM: effective level = 0, configured level = 0, file system access share name = 'MSSQLSERVER2008'.
2010-05-31 11:22:57.19 spid7s SQL Trace ID 1 was started by login "sa".
2010-05-31 11:22:57.19 spid7s Starting up database 'mssqlsystemresource'.
2010-05-31 11:22:57.20 spid7s The resource database build version is 10.00.1600. This is an informational message only. No user action is required.
2010-05-31 11:22:57.33 spid10s Starting up database 'model'.
2010-05-31 11:22:57.34 spid7s Server name is 'PAB-SRV-02\MSSQLSERVER2008'. This is an informational message only. No user action is required.
2010-05-31 11:22:57.34 spid7s Information*: aucune langue prise en charge en texte intégral n'a été trouvée.
2010-05-31 11:22:57.34 spid7s Starting up database 'msdb'.
2010-05-31 11:22:57.39 spid10s Clearing tempdb database.
2010-05-31 11:22:57.52 spid10s Starting up database 'tempdb'.
2010-05-31 11:22:57.55 spid13s The Service Broker protocol transport is disabled or not configured.
2010-05-31 11:22:57.55 spid13s The Database Mirroring protocol transport is disabled or not configured.
2010-05-31 11:22:57.55 spid13s Service Broker manager has started.
2010-05-31 11:22:57.56 spid7s Recovery is complete. This is an informational message only. No user action is required.
2010-05-31 11:22:57.64 Serveur A self-generated certificate was successfully loaded for encryption.
2010-05-31 11:22:57.64 Serveur Server is listening on [ 'any' <ipv4> 1433].
2010-05-31 11:22:57.64 Serveur Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\MSSQLSERVER2008 ].
2010-05-31 11:22:57.64 Serveur Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$MSSQLSERVER2008\sql\query ].
2010-05-31 11:22:57.66 Serveur Server is listening on [ 127.0.0.1 <ipv4> 1883].
2010-05-31 11:22:57.66 Serveur Dedicated admin connection support was established for listening locally on port 1883.
2010-05-31 11:22:57.67 Serveur The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/PAB-SRV-02.Palaisdurosaire.com:MSSQLSERVER2008 ] for the SQL Server service.
2010-05-31 11:22:57.67 Serveur The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/PAB-SRV-02.Palaisdurosaire.com:1433 ] for the SQL Server service.
2010-05-31 11:22:57.67 Serveur SQL Server is now ready for client connections. This is an informational message; no user action is required.

Par contre, même avec le lien que tu m'envois, je ne comprends toujours pas comment c'est possible. Mais peu importe.

Pascal semblait indiquer que les Named Pipes n'étaient pas une solution top. Il vaut mieux forcer une connexion de type TCP/IP ?

[dbaffaleuf]

Hello:

1) Avec NP activé côté instance et client, normalement un:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sqlcmd -U... -P... -Snp:'\\.\pipe\MSSQL$MSSQLSERVER2008\sql\query'

doit fonctionner.

2) Que le protocole soit désactivé (DISABLENETWORKPROTOCOL=1) ou pas (DISABLENETWORKPROTOCOL=0), LPC reste actif.

3) NP est taillé pour les réseaux de faible envergure. Je suis d'accord avec Frédéric, il vaut mieux utiliser TCP à chaque fois que c'est possible. Il n'a aucune plus-value en remote par rapport à TCP parce qu'il est de toutes façons encapsulé dans TCP pour le transport. En local, il permet de ne pas passer par la stack TCP, mais LPC va encore plus vite. Donc pas beaucoup d'intérêt.

David B.

[FMJ]

Bonjour,

Alors infoutu de comprendre ce qui ne va pas au niveau local avec la connexion SQL Management Studio mais en tout cas ça fonctionne très bien à distance (SQLCMD ou Administrateur de source de données).

Pour ton aide dbaffaleuf