Quantcast
Channel: Microsoft SQL Server
Viewing all 20 articles
Browse latest View live

The SQL Network Interface library was unable to register SPN

$
0
0




The SQL Network Interface library was unable to register SPN.


Problem

In the SQL Server error log you got the following message:


The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

To understand the error you can transcribe the error message 0x2098 in a more readable.

ERROR_DS_INSUFF_ACCESS_RIGHTS

8344 (0x2098)

Insufficient access rights to perform the operation.


This error message indicates that the service account SQL server does not have sufficient rights to register the SPN.


Cause

SPNs are used by the Kerberos authentication protocol. If the account of the proceeding is known, the Kerberos authentication can be used to provide mutual authentication by the client and server. If the account of the proceedings is not known, NTLM authentication, which provides only authentication of the client by the server is used.

If you run SQL Server under the LocalSystem account, the SPN is automatically registered as SQL registering with the machine account that has the right to create an SPN default. So Kerberos interacts successfully with the server running SQL Server.

However, if you run SQL Server under a domain account or a local account, the attempt to create the SPN may fail. When creating the service principal name fails, this means that no SPN is set for the service that is running SQL Server.



Solution


Therefore, you must implement a solution to that the SPN is created for your SQL Server instance where you want to use the Kerberos protocol.


Method 1 : The method recommended by Microsoft Support. You can give in Active Directory rights below to the service account of SQL Server:
- Read servicePrincipalName
- Write servicePrincipalName

Method 2 : You can also give him the rights manually using the tool SetSPN.(http://msdn.microsoft.com/fr-fr/library/cc280459.aspx )

For SQL server Standalone

SetSPN -A MSSQLSvc/<ComputerName>.<DomainName>:<port> <AccountName>

So for a multi-server instance you must configure the SPN for each instance, for each instance of SQL Server usefulness port TCP / IP only. For the port of the proceeding open SQL Server Configuration Manager>> Right click the instance>> TCP / IP protocol (default port)

Pour un cluster

SetSPN -A MSSQLSvc/<virtualName>.<DomainName>:<port> <AccountName>
SetSPN -A MSSQLSvc/<virtualName>.<DomainName> <AccountName>

For an instance of SQL Server cluster, you must use the FQDN of the virtual SQL server. You must also configure the SPN with a port and a second SPN without the port.


Verification

Then you can confirm that the operation went smoothly with the following command:
SetSPN -L <AccountName>

SQL server side to check, you can use the DMV sys.dm_exec_connections with the column auth_scheme :
select auth_scheme from sys.dm_exec_connections where session_id=@@spid
If kerberos is used, you should see "KERBEROS".


Documentation



How to: Enable Kerberos Authentication on a SQL Server Failover Cluster
http://msdn.microsoft.com/en-us/library/ms189585(SQL.90).aspx

Registering a Service Principal Name
http://msdn.microsoft.com/en-us/library/ms191153.aspx

How to configure SQL Server 2005 Analysis Services to use Kerberos authentication
http://support.microsoft.com/kb/917409

How to make sure that you are using Kerberos authentication when you create a remote connection to an instance of SQL Server 2005
http://support.microsoft.com/kb/909801

You cannot start the SQL Server Agent service of a failover cluster of SQL Server 2005 if the build of SQL Server is 3179 or a later build
http://support.microsoft.com/kb/943525

Registering Kerberos Service Principal Names
http://msdn2.microsoft.com/en-us/library/ms178119.aspx

How to Configure the Service Principal Name
http://msdn.microsoft.com/en-us/library/ms942980.aspx

How to troubleshoot the "Cannot generate SSPI context" error message
http://support.microsoft.com/kb/811889

Enable Kerberos authentication for virtual servers
http://technet.microsoft.com/en-us/library/cc780918.aspx

How to: Enable Kerberos Authentication on a SQL Server Failover Cluster
http://msdn.microsoft.com/en-us/library/ms189585(SQL.90).aspx

Best practices for configuring and operating server clusters
http://technet.microsoft.com/en-us/library/cc785714.aspx

How to use Kerberos authentication in SQL Server
http://support.microsoft.com/kb/319723/en-us

Michel Degremont 
| Microsoft EMEA
Product Support Services Developer - SQL Server Core Engineer |

SQL Server 2008 connectivity issue : cannot generate SSPI context

$
0
0

   

Problem description: We were not able to make a connection on SQL Server 2008 from a remote server with Windows account. We got the error message: cannot generate SSPI context:


9649 A security (SSPI) error occurred when connecting to another service broker: . Check the Windows Event Log for more information.
...
11248 A corrupted message has been received. The SSPI login header is invalid.
...
17806 SSPI handshake failed with error code X, state %d while establishing a connection with integrated security; the connection has been closed. 

...
Connection handshake failed.

 
Work done: We followed the troubleshooting step below:

Step 1:  made a  TELNET on machine port and confirmed that the port of SQL Server instance was open

Step 2:  We checked if the SPN for my instance SQL server exist with command below:

Start >> Run >> CMD >> Setspn -L <YourSQLServiceAccount>

Registered ServicePrincipalNames for CN=svc-mssql-sgbd,OU=Users,OU=_Paris,DC=puteaux,DC=net:
        MSSQLSvc/serverName:PORT
        MSSQLSvc/serverName


Step 3: From my remote server, I used an UDL file to make a connection.

Click right on your desktop >> new file >> then rename your text file by myTest.UDL.


 
Double click on it. Click on the tab PROVIDER. And select SQL Server Native client 10.0

     I tried to make a connection with another protocol, like Name Pipe.
     Np:<ServerName>\<IntanceName>  
          Works fine

     Then I tried with TCP protocol with SQL authentication 
     tcp:<ServerName>\<IntanceName>
           Works fine

      Then I tried with TCP protocol with Windows authentication 
     tcp:<ServerName>\<IntanceName>  
          Failed with error: cannot generate SSPI context

     Then I tried with TCP protocol with Windows authentication and the port
     tcp:<ServerName>\<IntanceName>,PortNumberOfYourSQLInstance  
          Failed with error: cannot generate SSPI context

     Then I tried with TCP protocol with another account Windows authentication 
     tcp:<ServerName>\<IntanceName>
           Works fine

 

  

 

 

Cause: we enabled the verbose logging to Kerberos following the article Microsoft KB: http://support.microsoft.com/kb/262177 .

And we found out inside Windows system event the error message:

The kerberos SSPI package generated an output token of size 12536 bytes, which was too large to fit in the token buffer of size 12535 bytes, provided by process id 4.
The output SSPI token being too large is probably the result of the user
myUser@myDomain.com  being a member of a large number of groups.
It is recommended to minimize the number of groups a user belongs to. If the problem can not be corrected by reduction of the group memberships of this user, please contact your system administrator to increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize.

 

 

Resolution: We increased the maximum token size following the article KB to get back in production : http://support.microsoft.com/kb/327825 ,  then customer investigates to see why this user being a member of a large number of groups.

 

 

Related Resources:

     The SQL Network Interface library was unable to register SPN

     How to troubleshoot the "Cannot generate SSPI context" error message

     “Cannot Generate SSPI Context” error message, more comments for SQL Server

Michel Degremont | Premier Field Engineer - SQL Server Core Engineer |

Use a DNS alias for SSAS 2005/2008 instance

$
0
0

You would like to configure a DNS alias (CName) for each server to  redirect transparently clients for high availability.

There is no indication against to use a DNS alias, you can use CNAME to connect to SSAS 2005 or greater. However there are some considerations to take into account.

1. Be carefully on cluster system

2. Be sure that you can “reverse lookup” the CNAME / Alias. SSAS has to reverse lookup the hostname during connection 

3.  Changing the DNS Alias: DNS caching might cause some delay
- Client side cache: It can be cleared with ipconfig /flushdns
- Server Side cache : Depends on the structure, by multilevel structure multiple caches might exist Clearcache possible with dnscmd or GUI (there are settings for the cache lifetime but it is not recommended to change them (it might increase the traffic on the DNS server))

4. Cannot connect locally to your SSAS instance using DNS alias

5.  As the alias uses only server name you cannot configure the protocol , the name of the instance or the port.

6.  At kerberos level you can have false SPN. The SPN needs to be re-registered on the alias name too.

7.  At TCP level you can have errors

8.  DNS will no provide an port information to clients.  If Default instance is listening on a non-default port (SQL Browser cannot redirect) , then port has to be defined in the connection string.


You can create a DNS alias following this article kb: How to set up application names in SQL Server 2000 Analysis Services


Connect bug: Create and alias to a (named) instance of Analysis Services 2005/2008

 

Michel Degremont | Premier Field Engineer - SQL Server Core Engineer |

The SQL Network Interface library was unable to register SPN

$
0
0




The SQL Network Interface library was unable to register SPN.


Problem

In the SQL Server error log you got the following message:


The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

To understand the error you can transcribe the error message 0x2098 in a more readable.

ERROR_DS_INSUFF_ACCESS_RIGHTS

8344 (0x2098)

Insufficient access rights to perform the operation.


This error message indicates that the service account SQL server does not have sufficient rights to register the SPN.


Cause

SPNs are used by the Kerberos authentication protocol. If the account of the proceeding is known, the Kerberos authentication can be used to provide mutual authentication by the client and server. If the account of the proceedings is not known, NTLM authentication, which provides only authentication of the client by the server is used.

If you run SQL Server under the LocalSystem account, the SPN is automatically registered as SQL registering with the machine account that has the right to create an SPN default. So Kerberos interacts successfully with the server running SQL Server.

However, if you run SQL Server under a domain account or a local account, the attempt to create the SPN may fail. When creating the service principal name fails, this means that no SPN is set for the service that is running SQL Server.



Solution


Therefore, you must implement a solution to that the SPN is created for your SQL Server instance where you want to use the Kerberos protocol.


Method 1 : The method recommended by Microsoft Support. You can give in Active Directory rights below to the service account of SQL Server:
- Read servicePrincipalName
- Write servicePrincipalName

Method 2 : You can also give him the rights manually using the tool SetSPN.(http://msdn.microsoft.com/fr-fr/library/cc280459.aspx )

For SQL server Standalone

SetSPN -A MSSQLSvc/<ComputerName>.<DomainName>:<port> <AccountName>

So for a multi-server instance you must configure the SPN for each instance, for each instance of SQL Server usefulness port TCP / IP only. For the port of the proceeding open SQL Server Configuration Manager>> Right click the instance>> TCP / IP protocol (default port)

Pour un cluster

SetSPN -A MSSQLSvc/<virtualName>.<DomainName>:<port> <AccountName>
SetSPN -A MSSQLSvc/<virtualName>.<DomainName> <AccountName>

For an instance of SQL Server cluster, you must use the FQDN of the virtual SQL server. You must also configure the SPN with a port and a second SPN without the port.


Verification

Then you can confirm that the operation went smoothly with the following command:
SetSPN -L <AccountName>

SQL server side to check, you can use the DMV sys.dm_exec_connections with the column auth_scheme :
select auth_scheme from sys.dm_exec_connections where session_id=@@spid
If kerberos is used, you should see "KERBEROS".


Documentation



How to: Enable Kerberos Authentication on a SQL Server Failover Cluster
http://msdn.microsoft.com/en-us/library/ms189585(SQL.90).aspx

Registering a Service Principal Name
http://msdn.microsoft.com/en-us/library/ms191153.aspx

How to configure SQL Server 2005 Analysis Services to use Kerberos authentication
http://support.microsoft.com/kb/917409

How to make sure that you are using Kerberos authentication when you create a remote connection to an instance of SQL Server 2005
http://support.microsoft.com/kb/909801

You cannot start the SQL Server Agent service of a failover cluster of SQL Server 2005 if the build of SQL Server is 3179 or a later build
http://support.microsoft.com/kb/943525

Registering Kerberos Service Principal Names
http://msdn2.microsoft.com/en-us/library/ms178119.aspx

How to Configure the Service Principal Name
http://msdn.microsoft.com/en-us/library/ms942980.aspx

How to troubleshoot the "Cannot generate SSPI context" error message
http://support.microsoft.com/kb/811889

Enable Kerberos authentication for virtual servers
http://technet.microsoft.com/en-us/library/cc780918.aspx

How to: Enable Kerberos Authentication on a SQL Server Failover Cluster
http://msdn.microsoft.com/en-us/library/ms189585(SQL.90).aspx

Best practices for configuring and operating server clusters
http://technet.microsoft.com/en-us/library/cc785714.aspx

How to use Kerberos authentication in SQL Server
http://support.microsoft.com/kb/319723/en-us

Michel Degremont 
| Microsoft EMEA
Product Support Services Developer - SQL Server Core Engineer |

SQL Server 2008 problème de connectivité : Impossible de générer un contexte SSPI

$
0
0

   

Description du problème :  Impossible de faire une connexion sur une instance  SQL Server 2008 depuis un serveur distant avec un compte Windows. Nous  obtenons le message d'erreur : Impossible de générer un contexte SSPI.


Tests réalisés : Nous avons suivi les étapes ci-dessous :

Etape 1:  Nous avons exécuté un   TELNET sur le machine et le port. Nous avons confirmé que le port SQL était ouvert.

Etape 2:  Nous avons vérifié que les SPN pour notre instance SQL Server existe avec la commande ci-dessous :

Démarrer >> Exécuter... >> CMD >> Setspn -L <NomDeVotreCompteDeServicePourSQL>

Registered ServicePrincipalNames for CN=svc-mssql-sgbd,OU=Users,OU=_Paris,DC=puteaux,DC=net:
        MSSQLSvc/serverName:PORT
        MSSQLSvc/serverName


Etape 3: Depuis le serveur distant, j'ai utilisé un fichier UDL pour réaliser une connexion sans passer par l'application.

Clic droit sur mon bureau  >> nouveau fichier >> puis renommer l'extension de votre fichier texte avec le nom suivant :  myTest.UDL.


 
Double cliquer sur le fichier myTest.UDL. Puis sur l'onglet FOURNISSEUR. Et selectionner le provider : SQL Server Native client 10.0

     J'ai essayé de faire une connexion avec un autre protocol réseau, comme  Name Pipe.
     Np:<ServerName>\<IntanceName>  
          La connexion a fonctionné


     Puis j'ai forcé le protocol TCP mais avec une authentification  SQL  
     tcp:<ServerName>\<IntanceName> 
          La connexion a fonctionné

     Puis j'ai essayé toujours avec le protocol TCP mais avec une authentification  Windows 
     tcp:<ServerName>\<IntanceName>  
          La connexion a échoué avec le mesage : Impossible de générer un contexte SSPI

     Puis j'ai re essayé avec le protocol TCP, l'authentification, mais en forçant le port SQL
     tcp:<ServerName>\<IntanceName>,PortNumberOfSQL  
          La connexion a échoué avec le mesage : Impossible de générer un contexte SSPI

     Pour terminé, j'ai essayé toujours en TCP mais avec un autre compte Windows 
     tcp:<ServerName>\<IntanceName> 
          La connexion a fonctionné

 

 

Cause : Nous donc un problème avec les connexions TCP pour un compte Windows précis. Nous avons activé un mode plus verbeux de logs pour capturer les messages kerberos en suivant l'article : http://support.microsoft.com/kb/262177 .

Et nous avons découvert le message d'erreur ci-dessous dans le journal d'événement system :

The kerberos SSPI package generated an output token of size 12536 bytes, which was too large to fit in the token buffer of size 12535 bytes, provided by process id 4.
The output SSPI token being too large is probably the result of the user
myUser@myDomain.com  being a member of a large number of groups.
It is recommended to minimize the number of groups a user belongs to. If the problem can not be corrected by reduction of the group memberships of this user, please contact your system administrator to increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize.

 

 

Résolution : Nous avons augmenté la taille du MaxTokenSize pour faire repartir la production. : http://support.microsoft.com/kb/327825 , puis le client a recherché pourquoi cet utilisateur est un membre d'un grand nombre de groupes.

 

 

Ressources annexes :

     The SQL Network Interface library was unable to register SPN

     How to troubleshoot the "Cannot generate SSPI context" error message

     “Cannot Generate SSPI Context” error message, more comments for SQL Server

Michel Degremont | Premier Field Engineer - SQL Server Core Engineer |

SQL Server 2008 problema de conectividad: No se puede generar contexto SSPI

$
0
0

   

Descripción del problema: No hemos podido establecer una conexión en SQL Server 2008 desde un servidor remoto con cuenta de Windows. Tenemos el mensaje de error: No se puede generar contexto SSPI.


Trabajo realizado: Hemos seguido el paso de solución de problemas a continuación:

Paso 1:  Hizo una  TELNET en el puerto de la máquina y confirmó que el puerto de la instancia de SQL Server estaba abierto.

Paso 2:  Se verificaron si el SPN para mi instancia del servidor SQL existen con el comando a continuación:

Inicio >> Ejecutar >> CMD >> Setspn -L <SuCuentaDeServicioDeSQL>

Registered ServicePrincipalNames for CN=svc-mssql-sgbd,OU=Users,OU=_Paris,DC=puteaux,DC=net:
        MSSQLSvc/serverName:PORT
        MSSQLSvc/serverName


Paso 3: Se verificaron si el SPN para mi instancia del servidor SQL existen con el comando a continuación:

Haga clicderechoen elescritorio >>Archivo >> Nuevo >>cambie el nombre desu archivo detextopormyTest.UDL.


 
Haga doble clic en él. Haga clic en la ficha del PROVEEDOR. Y seleccione SQL Server Native client 10.0

     Traté de hacer una conexión con otro protocolo, como Name Pipe.
     Np:<ServerName>\<IntanceName>  
          Funciona bien

     A  continuación, traté de hacer una conexión con protocolo TCP con SQL autenticación
     tcp:<ServerName>\<IntanceName>
          Funciona bien

     A  continuación, traté de hacer una conexión con protocolo TCP con  Windows autenticación
     tcp:<ServerName>\<IntanceName>  
          Se produjo el error: No se puede generar contexto SSPI

      A continuación, traté de hacer una conexión con protocolo TCP con  Windows autenticación y con el puerto
     tcp:<ServerName>\<IntanceName>,PortNumberOfYourSQLInstance  
          Se produjo el error: No se puede generar contexto SSPI

     Luego he intentado con el protocolo TCP con otra cuenta de la autenticación de Windows 
     tcp:<ServerName>\<IntanceName>
          Funciona bien

 

 

Causa: Hemos habilitado el registro detallado de Kerberos después del artículo de Microsoft Knowledge Base: http://support.microsoft.com/kb/262177 .

Y nos encontramos en del sistema dentro de Windows, el mensaje de error :

The kerberos SSPI package generated an output token of size 12536 bytes, which was too large to fit in the token buffer of size 12535 bytes, provided by process id 4.
The output SSPI token being too large is probably the result of the user
myUser@myDomain.com  being a member of a large number of groups.
It is recommended to minimize the number of groups a user belongs to. If the problem can not be corrected by reduction of the group memberships of this user, please contact your system administrator to increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize.

 

 

Resolución: Hemos aumentado el tamaño maximumtoken siguientes el artículo de Knowledge Base para volver a la producción : http://support.microsoft.com/kb/327825 ,  entonces el cliente investiga para ver por qué este usuario es miembro de un gran número de grupos.

 

 

Recursos relacionados::

     The SQL Network Interface library was unable to register SPN

     How to troubleshoot the "Cannot generate SSPI context" error message

     “Cannot Generate SSPI Context” error message, more comments for SQL Server

Michel Degremont | Premier Field Engineer - SQL Server Core Engineer |

SQL Server 2008 connectivity issue : cannot generate SSPI context

$
0
0

   

Problem description: We were not able to make a connection on SQL Server 2008 from a remote server with Windows account. We got the error message: cannot generate SSPI context:


9649 A security (SSPI) error occurred when connecting to another service broker: . Check the Windows Event Log for more information.
...
11248 A corrupted message has been received. The SSPI login header is invalid.
...
17806 SSPI handshake failed with error code X, state %d while establishing a connection with integrated security; the connection has been closed. 

...
Connection handshake failed.

 
Work done: We followed the troubleshooting step below:

Step 1:  made a  TELNET on machine port and confirmed that the port of SQL Server instance was open

Step 2:  We checked if the SPN for my instance SQL server exist with command below:

Start >> Run >> CMD >> Setspn -L <YourSQLServiceAccount>

Registered ServicePrincipalNames for CN=svc-mssql-sgbd,OU=Users,OU=_Paris,DC=puteaux,DC=net:
        MSSQLSvc/serverName:PORT
        MSSQLSvc/serverName


Step 3: From my remote server, I used an UDL file to make a connection.

Click right on your desktop >> new file >> then rename your text file by myTest.UDL.


 
Double click on it. Click on the tab PROVIDER. And select SQL Server Native client 10.0

     I tried to make a connection with another protocol, like Name Pipe.
     Np:<ServerName>\<IntanceName>  
          Works fine

     Then I tried with TCP protocol with SQL authentication 
     tcp:<ServerName>\<IntanceName>
           Works fine

      Then I tried with TCP protocol with Windows authentication 
     tcp:<ServerName>\<IntanceName>  
          Failed with error: cannot generate SSPI context

     Then I tried with TCP protocol with Windows authentication and the port
     tcp:<ServerName>\<IntanceName>,PortNumberOfYourSQLInstance  
          Failed with error: cannot generate SSPI context

     Then I tried with TCP protocol with another account Windows authentication 
     tcp:<ServerName>\<IntanceName>
           Works fine

 

  

 

 

Cause: we enabled the verbose logging to Kerberos following the article Microsoft KB: http://support.microsoft.com/kb/262177 .

And we found out inside Windows system event the error message:

The kerberos SSPI package generated an output token of size 12536 bytes, which was too large to fit in the token buffer of size 12535 bytes, provided by process id 4.
The output SSPI token being too large is probably the result of the user
myUser@myDomain.com  being a member of a large number of groups.
It is recommended to minimize the number of groups a user belongs to. If the problem can not be corrected by reduction of the group memberships of this user, please contact your system administrator to increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize.

 

 

Resolution: We increased the maximum token size following the article KB to get back in production : http://support.microsoft.com/kb/327825 ,  then customer investigates to see why this user being a member of a large number of groups.

 

 

Related Resources:

     The SQL Network Interface library was unable to register SPN

     How to troubleshoot the "Cannot generate SSPI context" error message

     “Cannot Generate SSPI Context” error message, more comments for SQL Server

Michel Degremont | Premier Field Engineer - SQL Server Core Engineer |

Usar un alias de DNS para una instancia SSAS 2005/2008

$
0
0

Que le gustaría configurar un alias de DNS (CNAME) para cada servidor para redirigir de forma transparente los clientes de alta disponibilidad.

No hay ninguna indicación para utilizar un DNS contra alias CNAME que usted puede usar para conectarse a SSAS 2005 o mayor. Sin embargo hay algunas consideraciones a tener en cuenta.

1. Con cuidado con a cluster sistema

2. Asegúrese de que usted puede "reverse lookup" el CNAME/Alias​​. SSAS tiene que invertir de búsqueda el nombre de host durante la conexión.

3.  Cambiar el alias de DNS: DNS caching puede provocar algún retraso :
- Caché de cliente lado: Se puede borrar con el comando ipconfig / flushdns.
- Caché del lado del servidor: Depende de la estructura, por la estructura de varios niveles multiples caches pueden existir clearcache posible con dnscmd o GUI (hay configuraciones para la vida de cache pero no se recomienda para el cambio (que podría aumentar el tráfico en el servidor DNS)).

4. No se puede conectar a nivel local para la instancia de SSAS con el alias de DNS

5. A medida que el alias sólo utiliza el nombre del servidor no se puede configurar el protocolo, el nombre de la instancia o el puerto.

6. A nivel de kerberos se puede tener SPN falsa. El SPN es necesario volver a registrarse en el nombre del alias también.

7. En el nivel TCP que puede tener errores.

8. DNS no proporcionará una información del puerto a los clientes. Si la Instancia predeterminada escucha en un puerto no predeterminado (SQL Browser no puede redirigir) , entonce el puerto tiene que ser definido en la cadena de conexión.


 Puede crear un alias de DNS siguiente este artículo KB: Cómo configurar los nombres de aplicación de SQL Server 2000 Analysis Services


Connect bug: Create and alias to a (named) instance of Analysis Services 2005/2008

Michel Degremont | Premier Field Engineer - SQL Server Core Engineer |


Utilisez un alias DNS pour une instance SSAS 2005/2008

$
0
0

Vous souhaitez configurer un alias DNS (CNAME) pour chaque serveur afin rediriger de manière transparente des clients pour  de la haute disponibilité.

Il n'y a pas d'indication contre à l'utilisation d'un alias DNS, vous pouvez utiliser un CNAME pour vous connecter à vos instances  SSAS 2005 ou supérieur. Cependant il y a quelques considération à prendre en compte.

1. Attention dans un environnement en cluster.

2. Soyez sûr que vous pouvez  faire un "reverse lookup"  sur le CNAME/Alias. SSAS doit pouvoir faire une recherche inversé sur le nom d'hôte lors de la connexion

3.  Modification de l'alias DNS: DNS cache peut causer un certain delai
- Cache côté client: il peut être effacé avec ipconfig / flushdns
- Cache côté serveur: dépend de la structure, pour les structures multi-caches multiples il peut exister un ClearCache possible avec dnscmd ou GUI (il ya des paramètres pour la durée de vie du cache, mais il n'est pas recommandé de les changer (il pourrait augmenter le trafic sur le serveur DNS))

4. Impossible de se connecter localement à votre instance SSAS en utilisant l'alias DNS

5. Comme l'alias utilise le nom du serveur que vous ne pouvez pas configurer le protocole, le nom de l'instance ou le port.

6.  Au niveau kerberos vous pouvez avec un SPN faux. Le SPN a besoin d'être enregistré sur le nom de l'alias DNS aussi.

7.  Au niveau TCP vous pouvez avoir des erreurs.

8.  DNS ne fournira pas d'information sur le port à ses clients. Si l'instance par défaut écoute sur un défaut non-port (SQL Browser ne peut pas rediriger), le Port doit être défini dans la chaîne de connexion.


Vous pouvez créer un alias DNS en suivant l'article KB suivant : Comment configurer des noms d'application dans SQL Server 2000 Analysis Services


Connect bug: Create and alias to a (named) instance of Analysis Services 2005/2008

 

Michel Degremont | Premier Field Engineer - SQL Server Core Engineer |

Use a DNS alias for SSAS 2005/2008 instance

$
0
0

You would like to configure a DNS alias (CName) for each server to  redirect transparently clients for high availability.

There is no indication against to use a DNS alias, you can use CNAME to connect to SSAS 2005 or greater. However there are some considerations to take into account.

1. Be carefully on cluster system

2. Be sure that you can “reverse lookup” the CNAME / Alias. SSAS has to reverse lookup the hostname during connection 

3.  Changing the DNS Alias: DNS caching might cause some delay
- Client side cache: It can be cleared with ipconfig /flushdns
- Server Side cache : Depends on the structure, by multilevel structure multiple caches might exist Clearcache possible with dnscmd or GUI (there are settings for the cache lifetime but it is not recommended to change them (it might increase the traffic on the DNS server))

4. Cannot connect locally to your SSAS instance using DNS alias

5.  As the alias uses only server name you cannot configure the protocol , the name of the instance or the port.

6.  At kerberos level you can have false SPN. The SPN needs to be re-registered on the alias name too.

7.  At TCP level you can have errors

8.  DNS will no provide an port information to clients.  If Default instance is listening on a non-default port (SQL Browser cannot redirect) , then port has to be defined in the connection string.


You can create a DNS alias following this article kb: How to set up application names in SQL Server 2000 Analysis Services


Connect bug: Create and alias to a (named) instance of Analysis Services 2005/2008

 

Michel Degremont | Premier Field Engineer - SQL Server Core Engineer |

How a clustered instance of Analysis Services works

$
0
0

 

Analysis Services is clustered as  a generic service resource on a Windows failover cluster. This applies to 2005, 2008, 2008R2, and 2012.

 

Since SSAS 2005 version, Analysis Services is fully integrated into clustering Setup (the install of SQL):

        – SSAS 2005 cluster setup is adding the service on all cluster nodes on the same setup
        – SSAS 2008, the setup have to be done node by node Analysis Services is presented to the cluster as generic resource with the type Application Service and doesn’t implement his own explicit IsAlive method. Unlike SQL Server, Analysis Services doesn’t have a cluster resource .dll that knows how to do that work like connect to AS and run a simple query to check that it responds.

 

Possible cause of failure that is detected for an Application Service:

       – The service stopped(ie. crash, or was killed) then the cluster resource would notice
       – A dependency in the group where the generic service is configured failed (a disk fails or goes offline, an IP, virtual name, mount point, SQL server…other dependencies affecting the group)

 

Note : Application Service will NOT detect a hang situation in SSAS, where all connections are rejected.

 

Michel Degremont | Premier Field Engineer – SQL Server Core Engineer |

Moving SSAS Database to a new drive on same server

$
0
0

Problem description: After you moved SSAS databases to a new drive on the same server, you are not able to administrate  Analysis Service. SSAS databases is up and running. When you add a database or user, it appears that users are added successfully, but when going back out of the dialog nothing happened.


Work done:
To move you database to a new drive, you followed the step below.
  
   Step 1: With Microsoft SQL Server Management Studio, connect to Analysis Server, then right Click on the server and click on Properties.
   Step 2: Edit the path of you data directory. And replace the old path by the new one.
   Step 3: Stop the SQL Server Analysis Services Service.
   Step 4: Move the Data to the new directory location.
   Step 5: Start the SQL Server Analysis Services Service.
   Step 6: verify that you can browser all database.


Cause:
Inside the SSAS log, you can see an  issue relating to something not allowing SSAS to update or access this file

     Message: Service started. (Source: ?D:Logmsmdsrv.log, Type: 1, Category: 289, Event ID: 0x41210000)
     Message: The file ‘\?E:OLAPDatamaster.vmp’ could not be deleted.
     Please check the file for permissions. (Source: ?D:Logmsmdsrv.log, Type: 3, Category: 289, Event ID: 0xC121001F)

I run Process Monitor and after SSAS restart I saw an access denied on various file and also on master.vmp.


For insformation:
  The master.vmp file is the master version map that contains the GUIDS for all of the objects and the version of each object that currently exists on the server. When the server starts, it looks at the master.vmp file and need to update it ( More information with my colleague Karan)

 

Resolution: You can solve this issue you can give the right “Modify” to SSAS service account to this new data folder.


Others points:

1. A database can be moved in many ways (SSMS Attach/Detach, AMO, XMLA). You could find some various way in the bol (Move an Analysis Services Database)
2. You can only move the file regarding Data, Backup, Log or Temp. However it’s not supported to move manually the BIN and Config directory. You must reinstall your instance.

 

Michel Degremont | Premier Field Engineer – SQL Server Core Engineer |

8624 Internal Query Processor Error: The query processor could not produce a query plan

$
0
0

 

Problem description: We got some mini memory dump. In side our SQL error log, we can see the error message below

          Stack Signature for the dump is 0x00000000950A8E26
          External dump process return code 0x20000001.
          External dump process returned no errors.Error: 8624, Severity: 16, State: 116.
          Internal Query Processor Error: The query processor could not produce a query plan. For more information, contact Customer Support Services.
          ex_raise2: Exception raised, major=86, minor=24, state=116,

          severity=16, attempting to create symptom dump
          ex_raise2: Exception raised, major=86, minor=24, state=116, severity=16

 

 

Interesting link:  We found out a similar issue. However, I am in SQL Server 2005 SP4 (9.00.5000.00 (X64)), and the issue below was fixed in SQL 2005 SP2. E.G.    FIX: Error message when you run a query in Microsoft SQL Server 2005: “Msg 8624, Level 16, State 116 Internal Query Processor Error: The query processor could not produce a query plan”

 

 

Cause: We got the query from the dump, but you could also get the query with a profiler trace with the events TSQL SQL:BatchCompleted or Stored procedure RPC:Completed with Error and Waring Exception. We the query we are able to reproduce the issue each time. We saw that the dump was generated by statistics stream corrupted (spotted that in the generation script of the objects)

 

 

Resolution: We run an update statitics with fullscan to solve the issue on all objects called by the query.We run again the query and the issue didn’t occur.

 

Michel Degremont | Premier Field Engineer – SQL Server Core Engineer |

Keyword not supported: ‘applicationintent’

$
0
0

 

Problem description: When you try to connect to  your SQL Server by using powershell, .Net, sqlcmd… you got this error message:

System.ArgumentException: Keyword not supported: ‘applicationintent’.
   at System.Data.SqlClient.SqlConnectionStringBuilder.set_Item(String keyword, Object value)
   at System.Data.Common.DbConnectionStringBuilder.set_ConnectionString(String value)

 

Cause: The message occurs when you include ApplicationIntent=ReadOnly (AlwaysOn Availability Groups properties) in your connection string. And  the server does not recognize the property.

KB Extract number 2544514: “When the ApplicationIntent property is set to ReadOnly, the client requests a read access operation when it connects to an AlwaysOn-enabled database. The server will enforce the read-only access operation both at connection time, and during a USE database statement, but only to an AlwaysOn-enabled database. When the ApplicationIntent property is set to ReadWrite, the client requests a regular (read-write) access operation when it connects to an AlwaysOn-enabled database. The default setting for the ApplicationIntent property is ReadWrite.”

 

Resolution: You have to install the update that introduces support for the AlwaysOn features from SQL Server 2012

        –  Update 4.0.2 for Microsoft .NET Framework 4 – Runtime Update

       –   An update introduces support for the AlwaysOn features from SQL Server 2012 to the .NET Framework 3.5 SP1

 

 

Regards,

Michel Degremont | Xbox Live Music – DBA Team – SQL Server & PDW |

 

How configure correctly AlwaysOn readable secondary replica for applicationIntent

$
0
0

 

Hi all,

 

I would like to share with you an issue that I got recently because  I didn’t set  up correctly AlwaysOn to enable readable database on the secondary replica.

 

Problem description: When I am trying to connect to my application with .Net or PowerShell, I got the following issue only when I add ApplicationIntent=Readonly on my connection string:

Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : TCP Provider: No connection could be made because the target machine actively refused it..
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Login timeout expired.
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : A network-related or instance-specific error has occurred while establishing a connection to SQL Server
. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see
SQL Server Books Online..

Reproduction: I am able to reproduce with SQL CMD: sqlcmd -S myListener -E  -K ReadOnly -Q “SELECT @@SERVERNAME” However, when I remove -K ReadOnly, it works fine.

Other interesting stuff, I can see a login/logout on my primary server inside the profiler trace, but nothing on the secondary

 

Solution: In my case, the issue was that the read_only_routing port mismatch with the port of my instance. I enclose below what you have to look.

 

How configure correctly AlwaysOn readable secondary replica:

1.      Add Application Intent in the connection string by adding: ;ApplicationIntent=ReadOnly

2.      ALLOW_CONNECTIONS property of the secondary replica is READ_ONLY.

3.      The READ_ONLY_ROUTING_URL for each replica is set. The TCP port is a port number that is used by the Database Engine of the SQL Server instance

alteravailabilitygroupmyGroupName
modifyreplicaon‘myMachine1instanceName1′with
(secondary_role(read_only_routing_url=‘tcp://myMachine1:1433′))

GO

alteravailabilitygroupmyGroupName
modifyreplicaon‘myMachine2instanceName2′with
(secondary_role(read_only_routing_url=‘TCP://myMachine2:1433′))

 

4.       The READ_ONLY_ROUTING_LIST option must be set for each replica in the CREATE AVAILABILITY GROUP or ALTER AVAILABILITY GROUP Transact-SQL command, as part of the PRIMARY_ROLE replica options. The READ_ONLY_ROUTING_LIST can contain one or more routing targets. Multiple routing targets can be configured. Routing occurs in the order that targets are specified in routing list.

 alteravailabilitygroupmyGroupName
modifyreplicaon‘myMachine1instanceName1′with
(primary_role(read_only_routing_list=(‘myMachine2instanceName2′)))

GO

alteravailabilitygroupmyGroupName
modifyreplicaon‘myMachine2instanceName2′with
(primary_role(read_only_routing_list=(‘myMachine1instanceName1′)))

GO

Select Replica_Server_name,Endpoint_url,Secondary_Role_allow_Connections_Desc,Backup_Priority,  Read_only_Routing_URLfrom Sys.AVailability_replicas

selectdns_name,port,is_conformant,ip_configuration_string_from_cluster FROM sys.availability_group_listeners

 

5.       Then I installed the both KB to fix this issue System.ArgumentException: Keyword not supported: ‘applicationintent’.

 

6.       To enable Kerberos, I configured in Active Directory by a domain administrator for each availability group listener name

Configure SPN in AD for each AG Listener name – A Server Principal Name (SPN) must be configured in Active Directory by a domain administrator for each availability group listener name in order to enable Kerberos for the client connection to the availability group listener. When registering the SPN, you must use the service account of the server instance that hosts the availability replica . For the SPN to work across all replicas, the same service account must be used for all instances in the WSFC cluster that hosts the availability group. (http://msdn.microsoft.com/en-us/library/hh213417.aspx#SPNs)

             setspn -A MSSQLSvc/myListenerName.FQDN:1433  myDomainmyserviceAccount    

  

7. Configuring the Windows Firewall to Allow SQL Server Access

 

 

If you got any connectivity issues, I invite you to read: How to resolve SQL Server connectivity issues

 

 

Regards,

Michel Degremont | Xbox Live Music – DBA Team – SQL Server & PDW |


AlwaysOn warning: The current WSFC cluster quorum vote configuration is not recommended for this availablity group

$
0
0

 

Problem description: You have got odd number of nodes. To prevent possible ties in the quorum vote you added a witness disk to the cluster and adjusted the quorum mode in the cluster manager.

However, when you perform a failover from SSMS on our SQL Server 2012 Availability group, we got a validation WSFC quorum vote configuration warning with action required

Error message: The current WSFC cluster quorum vote configuration is not recommended for this availability group.

 

 

 

Cause: This issue occurs because of a known issue in Windows Server Failover Clustering.

 

 

Resolution: To resolve this issue, you have to apply the hotfix below  on all computers node of your cluster:

  

A hotfix is available to let you configure a cluster node that does not have quorum votes in Windows Server 2008 and in Windows Server 2008 R2
http://support.microsoft.com/kb/2494036

 

Current status: After applied the fix, you should see that the warning is vanished.

 

 

Regards,

Michel Degremont | Xbox Live Music – DBA Team – SQL Server & PDW |

 
 
 
 
 
 
 
 
 
 
 
 

 

 

How to create a dependency between two or more Availability Groups

$
0
0

Hi all,

 

Problem description: I got a specific scenario where I have to failover two or more AlwaysOn Availability Groups in the same time.  To explain by another way, I have to create a dependency between 2 Availability Groups. If one of them failover, the second one has to move also on the same node.

In my case, I have to do that because, I’m not allow to put in the same group all databases. And a third application has to perform a query (write/read) between N databases from two different 2 Availability Groups.

 

  

Action plan: As it’s not a normal or expecting behavior, I will share with you, how I did to perform this task.

 

Step 0: Copy past the script PowerShell below on all nodes involved (SQL_Node_1 and SQL_Node_2 and SQL_Node_3) inside C:\HADRON\failoverAutomaticHadronGroup.ps1

 

import-modulefailoverclusters
$Cluster_Name =  “myWindowsClusterName”;

 

$my_AG1_Name =“AG1″;
$my_AG2_Name =“AG2″;

# We are looking for the current node of my_AG1_Name
$AG_1  =get-clustergroup  -name$my_AG1_Name-Cluster$ClusterName|select-object  OwnerNode,State

 

# then We are looking for the current node of my_AG2_Name
$AG_2=get-clustergroup  -name“IngestPub”-Cluster$my_AG2_Name|select-object  OwnerNode,State

 

if($AG_1.OwnerNode.Name -ne$currentTriggerNode  -and$AG_2.OwnerNode.Name -eq$currentTriggerNode )
{   
          # so we move the group AG_1 to the same node of AG2
          Move-ClusterGroup$my_AG1_Name–Node$AG_2.OwnerNode.Name -Cluster$ClusterName ;
}
elseif ($AG_2.OwnerNode.Name -ne$currentTriggerNode  -and$AG_1.OwnerNode.Name -eq$currentTriggerNode )
{
          # so we move the group AG_2 to the same node of IngestPub
          Move-ClusterGroup$my_AG2_Name–Node$AG_1.OwnerNode.Name -Cluster$ClusterName
}

 

 

 

Step 1: Open eventvwr.msc

Step 2: Go on the chanel:  Application and Services Logs\Microsoft\Windows\FailoverClustering\Operationnal

Step 3: Select eventID 1201 (The Cluster service successfully brought the clustered service or application ‘XXXXXX’ online.)

Step 4: Right-click -> Attach Task to this Event

Step5: Check start a program

 

Step 6: Select the powershell script of the step 0

 

  •  Program/script : powershell.exe
  •  Add arguments : -Noninteractive –Noprofile –Command “&{C:\HADRON\failoverAutomaticHadronGroup.ps1}”

 

NB: To modify the task, open Task Scheduler, please go to the  Windows  Scheduled Task Microsoft-Windows-FailoverClustering_Operational_Microsoft-Windows-FailoverClustering_1201.

 

 

 

Regards,

Michel Degremont | Xbox Live Music – DBA Team – SQL Server & PDW |

 

 

Unable to install SCOM 2012 Reporting Services

$
0
0

Problem description: you are trying to install SCOM 2012, and the SQL Server reporting service 2012 part failed.

 

Error message:

         –> Inside SCOM Setup installation, you got the error message below

eThe specified SQL Server instance is not valid.  The possible causes of this problem include the following:
* SSRS has not been configured correctly
* Secure Socket Layer (SSL) is configured for the SQL Server Report Server.
* A proxy server is configured for the SQL Server Report Server.e

        –> And if you open your report server http://myserver/reportserver, you got the error message below

“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)”

 

Troubleshooting step:

Step 1: Go on the SSRS log file to get more detail. By default is here: C:Program FilesMicrosoft SQL ServerMSRSXX.MSSQLSERVERReporting ServicesLogFiles

Step 2: Open the last ReportServerService…txt, and have a look to the last error at the end of the file.

In my case, I have got this error:

ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: Unable to load assembly Microsoft.EnterpriseManagement.Reporting.Security, Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: Le serveur de rapports a rencontré une erreur de configuration.  —> System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.EnterpriseManagement.Reporting.Security’ or one of its dependencies. The system cannot find the file specified.

Cause: This issue is due to SCOM that it changes the configuration files of the SQL Reporting Service.

Resolution:

Choice 1: Uninstall and reinstall SSRS

Choice 2 : When SCOM 2012 change the SQL Reporting Service 2012 configuration files, it takes the backup of the Reporting Service’s configuration files as: RSReportServer.config.0 and RSReportServer.config.1.

          – So, go to C:Program FilesMicrosoft SQL ServerMSRSXX.MSSQLSERVERReporting ServicesReportServer.

         – Then remove the file RSReportServer.config. And rename RSReportServer.config.0 to  RSReportServer.config

 

 

 

More detail here: How to Install the Operations Manager Reporting Server
http://technet.microsoft.com/en-us/library/hh298611.aspx

 

Regards,

Michel Degremont | Xbox Live Music – DBA Team – SQL Server & PDW |

 

 

Command sp_cycle_agent_errorlog is failing

$
0
0

 

 

Problem description: on ours SQL Server 2008, when we execute “EXECUTE msdb.[dbo].[sp_cycle_agent_errorlog] “, we got the error message below:

    Msg 22022, Level 16, State 1, Line 0
    SQLServerAgent Error: 32.

Work done:

 

Step1: We can see that the log is recycled. The file SQLAGENT.OUT contains for each execution the message below:

   [412] Errorlog has been reinitialized.  See previous log for older entries.

Step2: Inside the procmon, we can see a          SHARING VIOLATION

 

Event Class:       File System
Operation:         CreateFile
Result:  SHARING VIOLATION
Path:     H:MSSQL10.MSSQLSERVERMSSQLLogSQLAGENT.OUT
Desired Access:               Read Attributes, Delete, Synchronize
Disposition:        Open
Options:              Synchronous IO Non-Alert, Open Reparse Point
ShareMode:      Read, Write, Delete

Step3: With process explorer, I didn’t see that another process owns the same file SQLAGENT.OUT

 

Cause: After investigation, we can see that SQLAgent.exe is locked by himself. If you run Handle you will see that 2 handle are opened. And it should be only one. It look like a handle leak.

 

 

C:>handle.exe -a sqlagent.out

 

SQLAGENT.EXE       pid: 13196  type: File           FA4: H:MSSQL10.MSSQLSERVER
MSSQLLogSQLAGENT.OUT
SQLAGENT.EXE       pid: 13196  type: File          10AC: H:MSSQL10.MSSQLSERVER
MSSQLLogSQLAGENT.OUT

 

C:>tasklist |findstr 13196
SQLAGENT.EXE                 13196 Services                   0     52 096 K

 

 

Current workaround: Restart SQL Agent service on server.

 

 NB : currently I am investigating my colleague from Microsoft Support (3rd December 2013)

 

Regards,

Michel Degremont | Xbox Live Music – Data Engineer – SQL Server & PDW |

SQL transaction log unexpecting grow on my published database

$
0
0

Problem description: The transaction log grow up without end.

 

Cause: After investigation we can confirm that the distributor database is with sync with backup option. And that cause the issue

 

Resolution: At this end to solve the issue, I remove this option that we don’t need. I also check this property to all our publised database to be sure on the impact. And get a back in recovery model simple

select @@SERVERNAME,DATABASEPROPERTYEX(‘DistributionDB’,‘IsSyncWithBackup’)

EXECUTE sp_replicationdboption@dbname=  ‘DistributionDB’,@optname=  ‘sync with backup’  ,  @value=  ‘false’

select @@SERVERNAME,DATABASEPROPERTYEX(‘DistributionDB’,‘IsSyncWithBackup’)

 
But if you need it, you could also  plan a backup log every hour and every day for your distributation base in recovery model FULL.

 

 

Work done : here I’m sharing my troubleshooting step that I did to understand this issue.

 

Step 1: I run the dbcc loginfo, and I found out that the number of VLF is increasing to 8135. Yesterday it was around 5000. That we can see that the status is 2, so almost all VLF are used and we are not able to truncate them.

 

Step 2: I had a look to see what the log is waiting to be reuse, we can see that we are pending replication.

select name,log_reuse_wait_descfromsys.databaseswherename=‘myDBName’

 name   log_reuse_wait_desc
‘myDBName’ REPLICATION

 

Step 3: I had a look to the Log reader and it was running and replicating the transactions on the distributor database. We saw that inside the verbos log level 2 that we enable.

-Publisher [myPublisherServer] -PublisherDB [myPublisherDB] -Distributor [MyDistributorServer] -DistributorSecurityMode 1  -Continuous -OutputVerboseLevel 2 -Output C:\ReplLog\ReplOutput.txt

Step 4: I enabled the Tracer to see the latency, and we don’t have any latencies on this replication.

 

Step 5:  “Oldest non-distributed LSN” does not change since a couple of days. I found that after  runing several time a DBCC OPENTRAN :

                        Transaction information for database ‘myDBName’.

                       Replicated Transaction Information:
                               Oldest distributed LSN     : (1218321:2940:24)
                               Oldest non-distributed LSN : (1218321:2959:1) –> this part didn’t change during serverals days

 

Step 6: Now the step was to see if the option synchWithBackup is enable the Distributor and the Publisher

On the distributor:  select @@servername, DATABASEPROPERTYEX(‘DistributionDbName’,’IsSyncWithBackup’)

 This option was at TRUE

On the publisher : select @@SERVERNAME, DATABASEPROPERTYEX(‘publisherDBName’,’IsSyncWithBackup’)

 This option was at  FALSE

For information this option means : The database is either a published database or a distribution database, and can be restored without disrupting transactional replication.

 

Step 7: To confirm the issue is due to this option, I put in the same recovery model the distributor database that the use db. Then I run a backup full an log

BACKUP DATABASE[distributionDB]TO  DISK=N’C:\mydump.BAK’;

BACKUP LOG[distributionDB]TO  DISK=N’C:\mydump.TRN’;

 

After this backup log all VLF on the published database become to 0 and the transaction log can be truncate now.

 

 

 

Regards,

Michel Degremont | Xbox Live Music – Data Engineer – SQL Server & PDW |

 

 

Viewing all 20 articles
Browse latest View live