Comment activer/désactiver l'accès aux données dans SQL Server (exemple T-SQL)

SQL Server dispose d'une option de configuration "accès aux données" qui active et désactive un serveur lié pour l'accès aux requêtes distribuées.

Si jamais vous obtenez une erreur "Le serveur n'est pas configuré pour l'ACCÈS AUX DONNÉES", vous devrez probablement activer l'accès aux données pour le serveur lié sur lequel vous essayez d'exécuter la requête distribuée. À l'inverse, il peut également arriver que vous deviez désactiver l'accès aux données.

Pour activer ou désactiver l'accès aux données, utilisez la sp_serveroption procédure stockée système. Exécutez-le sur le serveur à partir duquel vous avez l'intention d'exécuter des requêtes distribuées. L'exemple suivant montre comment procéder.

Exemple 1 - Activer l'accès aux données

Voici comment activer l'accès aux données.

EXEC sp_serveroption
  @server = 'sqlserver007',
  @optname = 'DATA ACCESS',
  @optvalue = 'TRUE';

Dans ce cas, le serveur s'appelle sqlserver007 , et j'ai défini le DATA ACCESS option sur TRUE .

Voici une façon plus concise de faire la même chose :

sp_serveroption 'sqlserver007', 'DATA ACCESS', 'TRUE';

L'exécution de l'un ou l'autre permettra l'accès aux données sur le serveur lié spécifié.

Au fait, le serveur lié spécifié peut être le serveur local si nécessaire. Il n'est pas nécessaire qu'il s'agisse d'un serveur distant.

Pour vérifier le paramètre d'accès aux données, exécutez une requête sur sys.servers vue du catalogue système.

SELECT 
  name,
  is_data_access_enabled 
FROM sys.servers;

Résultat :

+--------------+--------------------------+
| name         | is_data_access_enabled   |
|--------------+--------------------------|
| sqlserver007 | 1                        |
| Homer        | 1                        |
+--------------+--------------------------+

Encore une fois, vous exécutez ceci sur le serveur local - pas sur le serveur distant.

Exemple 2 - Désactiver l'accès aux données

Pour désactiver l'accès aux données, définissez simplement @optvalue à FALSE .

EXEC sp_serveroption
  @server = 'sqlserver007',
  @optname = 'DATA ACCESS',
  @optvalue = 'FALSE';

Vérifiez à nouveau le réglage.

SELECT 
  name,
  is_data_access_enabled 
FROM sys.servers;

Résultat :

+--------------+--------------------------+
| name         | is_data_access_enabled   |
|--------------+--------------------------|
| sqlserver007 | 0                        |
| Homer        | 1                        |
+--------------+--------------------------+

Sur quel serveur dois-je exécuter le code ?

Exécutez le code sur le serveur à partir duquel vous avez l'intention d'exécuter des requêtes distribuées.

Dans mon exemple, sqlserver007 est le nom du serveur local et Homer est un serveur distant/lié. Si je voulais exécuter des requêtes distribuées sur Homer , j'exécuterais le code sur sqlserver007 .

Je n'ai pas besoin de passer à Homer pour changer son réglage. En fait, il pourrait avoir un réglage différent de celui que j'applique à sqlserver007 .

Pour illustrer ce point, voici ce que j'obtiens si je compare les résultats du serveur lié avec le paramètre réel sur le serveur distant.

EXEC sp_serveroption
  @server = 'Homer',
  @optname = 'DATA ACCESS',
  @optvalue = 'TRUE';

SELECT 
  'From local',
  is_data_access_enabled 
FROM sys.servers
WHERE name = 'Homer'
UNION ALL
SELECT 
  'Remote setting',
  is_data_access_enabled 
FROM Homer.master.sys.servers
WHERE server_id = 0;

Résultat :

+--------------------+--------------------------+
| (No column name)   | is_data_access_enabled   |
|--------------------+--------------------------|
| From local         | 1                        |
| Remote setting     | 0                        |
+--------------------+--------------------------+

Dans ce cas, le serveur local a un paramètre différent de son homologue de serveur lié.

Et le fait que j'ai pu récupérer ces informations via une requête distribuée démontre que c'est le paramètre de mon propre serveur qui a activé la requête distribuée, pas celui du serveur distant.