PI Services

Le blog des collaborateurs de PI Services

SQL Server 2008 R2 – Erreur 7399 lors de la liaison d’un serveur SQL local à un serveur SQL distant

Problème :

Lors de la liaison d’un serveur SQL à un autre le message d’erreur suivant s’affiche" :

3_thumb2

Le fournisseur OLE DB “SQLNCLI10” du serveur lié “xxx” a rapporté une erreur. Echec de l’authentification.

Impossible d’initialiser l’objet de la source de données du fournisseur OLE DB “SQLNCLI10” du serveur lié “xxx”

Le fournisseur OLE DB “SQLNCLI10” du serveur lié “xxx” a retourné le message “Spécification d’autorisation non valide”. (Microsoft SQL Server, Erreur : 7399)

Cause :

Les principales causes sont les suivantes :

  • Le problème peut être lié au réseau, par exemple vouloir lié deux serveurs qui sont dans deux VLANs différents.
  • Il peut s’agir également d’un problème de configuration au niveau de l’authentification.
    Résolution :

Nous commençons par vérifier si les serveurs arrivent à communiquer entre eux en les pingant afin d’écarter un problème qui pourrait être lié au réseau. Une fois ce problème résolue, nous pouvons passer à la liaison de nos serveurs.

    Nous poursuivons ensuite par la configuration de la liaison entre les serveurs. Nous naviguons jusqu’au dossier Objets serveur du volet droit de navigation puis faisons un clic-droit sur Serveurs liés afin de commencer notre configuration.
    6_thumb
    Nous entrons le nom du serveur SQL que nous voulons lier et nous choisissons SQL Serveur comme type de serveur :

7_thumb4

Nous poursuivons avec l’onglet Sécurité, ou nous définissons un utilisateur qui appartient au serveur que nous voulons lier pour faire notre mappage de connexions entre les deux serveurs.

Enfin nous choisissons le contexte de sécurité “Seront effectuées dans le contexte de sécurité de la connexion actuelle” de notre liste puis validons la configuration en cliquant sur OK.

2_thumb11

Nous avons désormais lié notre serveur SQL local à notre serveur SQL distant tout en assurant la sécurité de notre environnement.

SQL Server : Erreur 4861 lors d’une opération BULK INSERT

Introduction

Dans le cadre d’une opération d’insertion en batch en utilisant la commande BULK INSERT sur un serveur de base de données SQL Server on peut être confronté à une erreur système d’exploitation indiquant qu’un problème d’ouverture du fichier source à cause d’un Accès refusé bloque l’exécution de l’opération.

image

image

Il faudra noter que l’exécution de la même requête sur le serveur SQL lui même ne génère par cette erreur mais s’exécutera sans aucun problème.  

Causes

Le fait que la requête s’exécute convenablement depuis le serveur de base de données lui et pas depuis une autre machine ou un poste client, exclu automatiquement le fait que le compte avec lequel la requête est lancée ne dispose pas des privilèges nécessaires pour la réalisation de cette opération.

Malgré tout, c’est bien un problème de sécurité qui est exposé par ce message d’erreur, en effet et vu que nous somme dans un contexte où la requête est lancée depuis un poste distant et qui procèdera à l'a lecture d’un fichier depuis un partage sur un autre serveur et qui fera appel à la procédure BULK INSERT sur le serveur de base de données, ce mécanisme et dans une infrastructure Windows implique le recourt à l’authentification Kerberos et bien sûr aux prérequis relatif à cette technologie.   

Résolution

Pour pouvoir exécuter la requête sans problème il existe deux méthodes:

Méthode 1

La première méthode est simple et elle consiste tout simplement à utiliser un compte SQL pour se connecter au serveur de base de données au lieu d’un compte Windows et bien sûre s’assurer que le compte de service du serveur de bases de données SQL Server accède au fichiers source, le login SQL devra bien sûr avoir le droit bulkadmin au niveau du serveur SQL.

Méthode 2

Configurer le serveur de base de données et le compte de service SQL pour permettre ce genre d’opération en :

Configurer le compte de service SQL

En ajoutant  le SPN MSSQLSvc au compte de service utilisé pour le démarrage du service SQL comme suit :

Si c’est une instance par défaut exécuter :

SETSPN –A MSSQLSvc/<fqdn du serveur SQL> <Nom du Compte de Service>

SETSPN –A MSSQLSvc/<fqdn du serveur SQL>:1433 <Nom du Compte de Service>

Si c’est une instance nommée:

SETSPN –A MSSQLSvc/<fqdn du serveur SQL>:<Nom de l’instance>

SETSPN –A MSSQLSvc/<fqdn du serveur SQL>:<Port d’écoute de l’instance>

Approuver le compte de service pour la délégation au niveau de l'AD.

image 

Configuration du compte machine du serveur de base de données

Approuver le compte machine du serveur de base de données pour la délégation au niveau de l’AD.

image

Sharepoint 2013 – Cannot connect to database master at SQL Server

Problème :

Lors du lancement de l'assistant de configuration de Sharepoint 2013, une erreur de connexion se produit sur la page de configuration des paramètres de la base de données de Sharepoint : “Cannot connect to database master at SQL Server…

image

clip_image001

Cause :

Les causes sont multiples. Il peut s’agir :

  1. D’un problème de pare-feu qui bloque le trafic entrant sur le serveur SQL sur le port 1433 ou tous les trafics entrants.
  2. De l’utilisateur spécifié pour la configuration n’a pas assez de permissions pour configurer notre ferme.
  3. D’un problème au niveau des paramètres de connexion de SQL Server avec le protocole TCP/IP qui est désactivé.
  4. Du service SQL Server Browser qui est désactivé.

    Résolution :
  • Dans le cas où il s’agit d’un problème de pare-feu

Nous devons ajouter une nouvelle règle aux pare-feu Windows autorisant le trafic entrant sur le serveur SQL.

Nous lançons le Windows Firewall with Advanced Security puis cliquez droit sur Inbound Rules pour créer une nouvelle règle :

image

Nous choisissons la règle qui concerne un port puis passez à la page suivante :

image

Cette règle s’applique sur le port 1433 en TCP :

image

Elle autorise les connexions entrantes vers le serveur SQL :

image

Et s’applique sur l’ensemble du domaine :

image

image

 

  • Dans le cas ou il s’agit d’un problème de droits insuffisants pour l’utilisateur
    Pour résoudre le problème lié à l’utilisateur, il faut lui attribuer les roles dbcreator et securityadmin sur le serveur SQL.

Nous vérifions que notre utilisateur a bien ces droits, si ce n’est pas le cas, nous les lui attribuions.

Lancez le SQL Server Management Studio, nous développons le dossier Security puis double-cliquons sur l’utilisateur en question pour accéder à ses propriétés. Nous naviguons jusqu’à l’onglet Server Roles et cochons dbcreator et securityadmin si ce n’est pas déjà fait puis validons l’opération en appuyant sur OK :

image

 

  • Dans le cas ou il s’agit d’un problème au niveau des paramètres de connexion de SQL Server

Nous lançons le SQL Server Configuration Manager puis nous naviguons dans le volet de droite et développons le menu SQL Native CLient 11.0 Configuration pour aller sur le Client Protocols.

Nous vérifions que notre protocole TCP/IP est bien activé. Si ce n’est pas le cas nous l’activons.

image

 

  • Dans le cas ou si s’agit d’un problème du service SQL Browser qui est désactivé
    Nous lançons le SQL Server Configuration Manager puis naviguons jusqu’aux services SQL “SQL Server Services. Nous vérifions l’état du service SQL Server Browser et voyons que le service est désactivé et arreté :

image

Nous commençons par changer le mode de démarrage du service en Manual afin de pouvoir activé le service :

image

Puis nous démarrons le service SQL Server Browser :

image

image

SQL Server – Cycle de vie du Support

 

Introduction

Avec l’arrivée des nouvelles technologies et des nouveaux produits, les entreprise sont amenées à mettre à niveau leurs architectures et faire évoluer leur parc applicatifs selon leurs besoin.

L’un des points cruciaux aussi qui pousse les entreprises à faire évoluer leurs plateforme est lié principalement à la supportabilité des produits eux même par l’éditeur.

SQL Server et comme tout autre produit dispose d’un cycle de vie de support qui varie d’une version et d’une édition à une autre, dans ce post j’ai essayé de regrouper le cycle de vie des dernières version de SQL Server de telle sorte qu’on puisse avoir trouver l’information rapidement.

Sachant que SQL Server 6.0, 6.5 et 7.0 ne sont plus supportés par l’éditeur voici la liste des dates clés pour les autres versions du produit :

  1. SQL Server 2000 : Le 9 Avril 2013 fin du support étendu
  2. SQL Server 2005 : Le 12 Avril 2016 fin du support étendu
  3. SQL Server 2008 : Le 9 Juillet 2019 fin du support étendu
  4. SQL Server 2008 R2 : Le 9 Juillet 2019 fin du support étendu
  5. SQL Server 2012 : Le 12 Juillet 2022 fin du support étendu

 

Et pour plus d’information voici le détail du cycle de vie de support de chaque version(Source: Microsoft Product Lifecycle Serach) :  

SQL Server 2012

 

Products Released

Lifecycle Start Date

Mainstream Support End Date

Extended Support End Date

Service Pack Support End Date

SQL Server 2012 Business Intelligence

5/20/2012

7/11/2017

7/12/2022

 

SQL Server 2012 Developer

5/20/2012

7/11/2017

7/12/2022

 

SQL Server 2012 Enterprise

5/20/2012

7/11/2017

7/12/2022

 

SQL Server 2012 Enterprise Core

5/20/2012

7/11/2017

7/12/2022

 

SQL Server 2012 Express

5/20/2012

7/11/2017

7/12/2022

 

SQL Server 2012 Standard

5/20/2012

7/11/2017

7/12/2022

 

SQL Server 2012 Web

5/20/2012

7/11/2017

7/12/2022

 

SQL Server 2008 R2

 

Products Released

Lifecycle Start Date

Mainstream Support End Date

Extended Support End Date

Service Pack Support End Date

SQL Server 2008 R2 Datacenter

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Developer

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Enterprise

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Express

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Express with Advanced Services

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Parallel Data Warehouse

11/9/2010

7/8/2014

7/9/2019

 

SQL Server 2008 R2 Service Pack 1

7/12/2011

Not Applicable

Not Applicable

10/8/2013

SQL Server 2008 R2 Service Pack 2

7/26/2012

Review Note

Review Note

 

SQL Server 2008 R2 Standard

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Standard Edition for Small Business

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Web

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Workgroup

7/20/2010

7/8/2014

7/9/2019

7/10/2012

 

SQL Server 2008

 

Products Released

Lifecycle Start Date

Mainstream Support End Date

Extended Support End Date

Service Pack Support End Date

SQL Server 2008 Developer

11/6/2008

7/8/2014

7/9/2019

4/13/2010

SQL Server 2008 Enterprise

11/7/2008

7/8/2014

7/9/2019

4/13/2010

SQL Server 2008 Express

11/11/2008

7/8/2014

7/9/2019

4/13/2010

SQL Server 2008 Express with Advanced Services

11/22/2008

7/8/2014

7/9/2019

4/13/2010

SQL Server 2008 R2 Datacenter

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Developer

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Enterprise

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Express

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Express with Advanced Services

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Parallel Data Warehouse

11/9/2010

7/8/2014

7/9/2019

 

SQL Server 2008 R2 Service Pack 1

7/12/2011

Not Applicable

Not Applicable

10/8/2013

SQL Server 2008 R2 Service Pack 2

7/26/2012

Review Note

Review Note

 

SQL Server 2008 R2 Standard

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Standard Edition for Small Business

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Web

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 R2 Workgroup

7/20/2010

7/8/2014

7/9/2019

7/10/2012

SQL Server 2008 Service Pack 1

3/31/2009

Not Applicable

Not Applicable

10/11/2011

SQL Server 2008 Service Pack 2

9/24/2010

Not Applicable

Not Applicable

10/9/2012

SQL Server 2008 Service Pack 3

10/6/2011

Review Note

Review Note

 

SQL Server 2008 Standard

11/6/2008

7/8/2014

7/9/2019

4/13/2010

SQL Server 2008 Standard Edition for Small Business

11/6/2008

7/8/2014

7/9/2019

4/13/2010

SQL Server 2008 Web

11/6/2008

7/8/2014

7/9/2019

4/13/2010

SQL Server 2008 Workgroup

11/6/2008

7/8/2014

7/9/2019

4/13/2010

 

SQL Server 2005

 

Products Released

Lifecycle Start Date

Mainstream Support End Date

Extended Support End Date

Service Pack Support End Date

SQL Server 2005 Compact Edition

2/19/2007

4/12/2011

4/12/2016

7/10/2007

SQL Server 2005 Developer Edition

1/14/2006

4/12/2011

4/12/2016

7/10/2007

SQL Server 2005 Enterprise Edition

1/14/2006

4/12/2011

4/12/2016

7/10/2007

SQL Server 2005 Enterprise Edition for Itanium-based Systems

1/14/2006

4/12/2011

4/12/2016

7/10/2007

SQL Server 2005 Enterprise X64 Edition

1/14/2006

4/12/2011

4/12/2016

7/10/2007

SQL Server 2005 Express Edition

6/1/2006

4/12/2011

4/12/2016

7/10/2007

SQL Server 2005 Express Edition with Advanced Services

7/16/2006

4/12/2011

4/12/2016

7/10/2007

SQL Server 2005 Service Pack 1

4/18/2006

Not Applicable

Not Applicable

4/8/2008

SQL Server 2005 Service Pack 2

2/19/2007

Not Applicable

Not Applicable

1/12/2010

SQL Server 2005 Service Pack 3

12/15/2008

Not Applicable

Not Applicable

1/10/2012

SQL Server 2005 Service Pack 4

12/13/2010

Review Note

Review Note

 

SQL Server 2005 Standard Edition

1/14/2006

4/12/2011

4/12/2016

7/10/2007

SQL Server 2005 Standard Edition for Itanium-based Systems

1/14/2006

4/12/2011

4/12/2016

7/10/2007

SQL Server 2005 Standard X64 Edition

1/14/2006

4/12/2011

4/12/2016

7/10/2007

SQL Server 2005 Workgroup Edition

1/14/2006

4/12/2011

4/12/2016

7/10/2007

 

SQL Server 2000

 

Products Released

Lifecycle Start Date

Mainstream Support End Date

Extended Support End Date

Service Pack Support End Date

SQL Server 2000 64-bit Edition

11/30/2000

4/8/2008

4/9/2013

7/11/2002

SQL Server 2000 Desktop Engine

11/30/2000

4/8/2008

4/9/2013

 

SQL Server 2000 Desktop Engine Release A

1/29/2003

4/8/2008

4/9/2013

 

SQL Server 2000 Developer Edition

11/30/2000

4/8/2008

4/9/2013

7/11/2002

SQL Server 2000 Enterprise Edition

11/30/2000

4/8/2008

4/9/2013

7/11/2002

SQL Server 2000 Reporting Services Service Pack 1

9/22/2004

Not Applicable

Not Applicable

7/11/2006

SQL Server 2000 Reporting Services Service Pack 2

4/22/2005

Review Note

Review Note

 

SQL Server 2000 Service Pack 1

6/12/2001

Not Applicable

Not Applicable

2/28/2002

SQL Server 2000 Service Pack 2

11/30/2001

Not Applicable

Not Applicable

4/7/2003

SQL Server 2000 Service Pack 3a

1/7/2003

Not Applicable

Not Applicable

7/10/2007

SQL Server 2000 Service Pack 4

5/6/2005

Review Note

Review Note

 

SQL Server 2000 Standard Edition

11/30/2000

4/8/2008

4/9/2013

7/11/2002

SQL Server 2000 Windows CE Edition 2.0

12/16/2002

1/8/2008

1/8/2013

 

SQL Server 2000 Workgroup Edition

6/1/2005

4/8/2008

4/9/2013

 

SQL Server 2008 R2 : Le nouveau né HP BDW !

 

Après le HP Business Decision Appliance et le HP Enterprise Data Wharehouse Appliance, le 6 Juin 2011 MS et HP viennent d’annoncer la sortie de HP Business Data Wharehouse Appliance.

Le nouveau né est une Appliance 4U préconfigurée et optimisée pour supporter des charges de travail Data Wharehouse pour des solutions atteignant les 5 TB de données.

Selon l’environnement du client l’Appliance peut être déployé et prêt à l’emploi en 10 minutes, basé sur l’architecture Fast Track 3.0 et conçu pour des performances maximales.

L’Appliance est constitué d’un seul serveur DL370 G6 configuré comme suit :

  • 96 GB de mémoire vive
  • 2 CPU Intel Xeon X5675 
  • 2 disques SAS de 300 Gb en RAID 1 pour Windows Server 2008 R2 Enterprise Edition qui est déjà préinstallé et licencié 
  • 22 disques SAS de 600 Gb pour le stockage
  • SQL Server 2008 R2 préinstallé mais sans licence

La procédure d’installation a été simplifiée au maximum, de telle sorte qu’elle est réduite à la réponse à quatre questions :

1- Quel est le mot de passe de l’administrateur?

2- Quel domaine l’Appliance doit rejoindre ?

3- Quel compte puis-je utiliser pour joindre le domaine ?

4- Quel compte AD devra joindre le groupe d’administrateurs locaux ?

 

Si vous voulez voir l'intérieur de la "bête" , cliquer ici

SQL Server – Changer l’emplacement par défaut des bases de données utilisateur et systèmes

L’emplacement par défaut des bases de données SQL Server est généralement <Dossier d'installation>\MSSQL.1\MSSQL\Data

SQL Server nous permet de modifier cet emplacement par défaut sauf qu’il faut faire attention que la procédure n’est pas la même pour les bases de données utilisateurs et les bases de données système.

Changement de l’emplacement par défaut des bases utilisateur

Pour modifier l’emplacement par défaut des base de donnés utilisateurs juste après l’installation de SQL Server :

- Ouvrir SQL Server Management Studio

- Avec le bouton droit de la souri cliquer sur Serveur | Propriétés

- Sélectionner la page Paramètres de base de données

ServerProp

- Au niveau de la section Emplacement de la base de données par défaut saisir les nouveau emplacements des fichiers de données et des fichiers Log

dbLocation 

Pour réaliser cette opération on peut aussi exécuter le code T-SQL suivant :

USE [master]
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultData', REG_SZ, N'E:\UserDB'
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultLog', REG_SZ, N'E:\UserLOG'
GO

Déplacement des bases de données systèmes

 

La base de données MASTER

  1. Changer les paramètres de démarrage de SQL Server en utilisant SQL Server Configuration Manager (Gestionnaire de configuration SQL Server)

configSQL

  1. Changer le chemin du fichier master.mdf en précisant le nouveau chemin devant la commutateur –d
  2. Changer  le chemin du fichier mastlog.ldf en précisant le nouveau chemin devant le commutateur –l
  3. Arrêter  le service SQL Server en exécutant NET STOP MSSQLSERVER (pour une instance nommée utiliser  NET STOP MSSQL$<Nom de l’instance>)
  4. Déplacer les fichier vers le nouvel emplacement
  5. Démarrer le service SQL Server en exécutant NET START MSSQLSERVER

 

Les bases de données MSDB et MODEL

Cette procédure s’applique à la base de données MSDB et MODEL :

Les scripts mentionnés concernent la base de données MSDB et il suffit de les adapter pour MODEL.

  • Démarrer un invite de commande (cmd)
  • Exécuter NET STOP MSSQLSERVER
  • Exécuter NET START MSSQLSERVER /c /m /T3608
  • Exécuter l’utilitaire SQLCMD (il faut s’assurer que tous les autres services SQL sont arrêtés et qu’aucune application ne tente de se connecter au serveur )
  • Au niveau de l’invite SQLCMD exécuter le script T-SQL Suivant :

      USE master
      Go
      sp_detach_db ‘msdb’
      Go

  • Déplacer  les fichiers msdbdata.mdf et msdglog.ldf dans le nouvel emplacement
  • Exécuter NET STOP MSSQLSERVER
  • Exécuter  NET START MSSQLSERVER
  • Lancer le script T-SQL suivant

      USE master
      Go
      sp_attach _db ‘msdb’ , ‘<nouvel emplacement>\msdbdata.mdf’, ‘<nouvel emplacement>\msdblog.ldf’
      Go

      La base de données TEMPDB

  • Exécuter le script T-SQL suivant :

USE master

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = 'tempdev',FILENAME = '<new location>\tempdb.mdf')

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = 'templog',FILENAME = '<new location>\templog.ldf')

GO

  • Exécuter NET STOP MSSQLSERVER
  • Déplacer les fichiers tempdb.mdf et templog.ldf au nouvel emplacement
  • Exécuter NET START MSSQLSERVER

    SQL Server – Erreur d’activation Service Broker dans MSDB

    Suite à la restauration de la base de données MSDB il se peut que le Service Broker ne s’active pas et ainsi on ne pourra plus utiliser certaines fonctionnalités comme la messagerie de base de données qui permet la notification des opérateurs en cas d’échec ou de réussite des travaux.

    Pour résoudre ce problème il suffit de créer un nouveau Service Broker au niveau de la base de données MSDB et de l’activer pour cela il faut exécuter les trois lot T-SQL suivants :

    ALTER DATABASE [MSDB] SET NEW_BROKER WITH ROLLBACK IMMEDIATE

    Go

    ALTER DATABASE [MSDB] SET NEW_BROKER

    Go

    ALTER DATABASE [MSDB] SET ENABLE_BROKER

    Go

    SQL Server 2008 – Réduction de la taille des fichiers Log

    Parmi les options de configuration  d’une base de données on trouve le mode de récupération qui peut être Complet (Full), Journalisé en bloc (Bulk-Logged) ou Simple (Simple).

    image

    Si le mode de récupération d’une base de données est différent du mode Simple, il faut impérativement mettre en place une stratégie de sauvegarde des fichiers journaux de cette base de données sinon les fichiers log n’arrêteront par de croitre et consommer de l’espace disque.

    Au cas où vous avez oublié de mettre en place cette stratégie et que votre disque commence à souffrir il faut impérativement réduire la taille des fichiers journaux volumineux, cet article décrit l’ensemble des actions à entreprendre pour réaliser cette action.

    Identifier le nom logique d’un fichier Log d’une base de données

    Pour identifier le nom logique d’un fichier journal d’une base de données nommée Demo il suffit d’exécuter la requête suivante :

    SELECT DB_NAME(database_id) AS [Base de données],name AS [Nom Logique] ,
    physical_name AS [Nom Physique]  FROM sys.master_files  
    WHERE DB_NAME(database_id) = 'Demo' AND type = 1

    Noter le nom qui apparaît au niveau de la colonne Nom Logique

    Sauvegarder la base de données et le fichier Log

    Avant de procéder à la réduction de la taille du fichier log et afin de sécuriser l’opération il faut procéder à une sauvegarde de la base de données et du fichier journal pour pouvoir la récupérer en cas de problème.

    Pour cela il suffit d’exécuter les scripts suivants :

    BACKUP DATABASE [Demo]
    TO  DISK = N'F:\Backup\Demo.BAK'
    WITH NOFORMAT, NOINIT, 
    NAME = N'Demo-Full Database Backup',
    SKIP, NOREWIND, NOUNLOAD,  STATS = 10
    GO

    BACKUP LOG [Demo]
    TO  DISK = N'F:\Backup\Demo.bak'
    WITH NOFORMAT, NOINIT
    NAME = N'Demo-Transaction Log  Backup',
    SKIP, NOREWIND, NOUNLOADSTATS = 10
    GO

    Réduire la taille du fichier log de la base de données

    On peut réduire la taille du fichier log en exécutant le script SQL Suivant

    USE [Demo]
    GO
    DBCC SHRINKFILE (N'Demo_log' , 0, TRUNCATEONLY)
    GO

    Ou

    En utilisant SQL Server Management Studio et en cliquant avec le bouton droit sur la base de données en question puis  sur Tasks ==> Shrink ==> Files

    image

    Au niveau de la fenêtre Shrink file – Demo.log :

    1. Vérifier que le type de fichier est bien Log
    2. Cocher la case Reduce unused space
    3. Cliquer sur Ok

      image

    Si la taille du fichier Log n’est pas réduite suite à cette opération chose qui peut survenir si la fin du fichier log est considérée par SQL Server comme portion active non réductible, on peut forcer l’opération de réduction en changeant le mode de récupération de la base de données vers le mode simple, exécuter l’opération de troncature une autre fois et ensuite remettre le mode de récupération de la base de données au mode Complet (Full).

    Pour changer le mode de récupération de la base vers le mode Simple exécuter le script suivant :

    USE [master]
    GO
    ALTER DATABASE [Demo] SET RECOVERY SIMPLE WITH NO_WAIT
    GO

    Pour remettre le mode de récupération à Complet exécuter le script suivant :

    USE [master]
    GO
    ALTER DATABASE [Demo] SET RECOVERY FULL WITH NO_WAIT
    GO

    Au niveau du script de la troncature on peut choisir la taille cible que doit prendre notre fichier log en utilisant la syntaxe suivante :

    USE [Demo]
    GO
    DBCC SHRINKFILE (N'Demo_log' , <Taille Cible en MB>)
    GO

    SQL Server 2008 : Types de sauvegardes et choix du mode de récupération d’une base de données

    Introduction

    Lors de la création d’une base de données SQL Server 2008 on peut choisir le mode de récupération à appliquer pour cette base de données. Ce choix ne doit pas être fait au hasard mais il doit répondre aux besoins de l’entreprise en termes de stratégie de sauvegarde et de récupération.

    Types de sauvegardes

    SQL Server 2008 offre une multitude de types de sauvegarde pour une base de données sauf que ces types de sauvegarde dépendent du mode de récupération choisi pour celle-ci.

    Les types de sauvegarde qu’on peut réaliser sur une base de données sont :

    1. Sauvegarde de données
    2. Sauvegarde des journaux de transactions
    3. Sauvegarde de type copie seule

     

    L’étendu d’une sauvegarde peut être soit une base de données complète, une base de données partielle ou un ensemble de fichiers ou groupes de fichiers. Pour chacun de ces étendues on peut faire soit des sauvegardes complètes soit des sauvegardes différentielles.

    Une sauvegarde différentielle dépend de la dernière sauvegarde complète réalisée avant celle-ci, la perte de la sauvegarde complète implique la perte de toutes les sauvegardes différentielles réalisées après.

    Chaque sauvegarde de base de données contient la portion du journal de transaction qui permet de remettre la base de données à la fin de l’opération de sauvegarde.

    Une sauvegarde de type copie seule (Copy Only) nous permet de réaliser des sauvegardes sans affecter la stratégie de sauvegarde mise en place, ce qui veut dire qu’une sauvegarde en copie seule même si c’est une sauvegarde complète n’affecte pas le chainage entre les sauvegardes différentielles réalisées après celle-ci et la sauvegarde complète normale réalisée avant elle.

    Mode de récupération

    Si le mode de récupération d’une base de données est Simple, la sauvegarde des journaux de transaction est désactivée pour celle-ci, en effet SQL Server prendra en charge la gestion des fichiers journaux et à chaque point de contrôle les parties inactives du journal seront tronquées.

    clip_image002

    Le mode de récupération Journalisé en bloc est un mode complémentaire au mode complet qui permet d’optimiser les opérations en bloc mais n’offre pas le même niveau de protection que le mode complet, en effet ce mode ne prend pas en charge la récupération de la base de données à une date et heure précise.

    Meilleures pratiques

    • Choisir le mode de récupération Simple pour les bases de données de développement et de test
    • Si votre base de données est configurée avec un mode de récupération complet ou journalisé en bloc il ne faut pas oublier de réaliser des sauvegardes des journaux de transaction.
    • Une sauvegarde différentielle d’une base de données contient toutes les pages de données modifiées depuis la dernière sauvegarde complète, sans la sauvegarde complète de référence une sauvegarde différentielle ne peut pas être restaurée ; dans le cas où on met en place une stratégie de sauvegarde à base de sauvegarde complète et différentielles il faut bien faire attention à ne pas perdre la sauvegarde complète.
    • L’application d’une mise à jour ou d’un patch de sécurité qui change le numéro de version de votre serveur SQL doit être suivi immédiatement d’une sauvegarde des bases de données système, en fait les anciennes sauvegardes seront obsolètes dans ce cas.

    SQL Server 2008 : Meilleures Pratiques pour le stockage

    L’optimisation des performances des serveurs SQL Server passe obligatoirement par la mise en place d’une infrastructure de stockage adéquate. Les consignes suivantes permettent d’améliorer les performances de vos serveurs de bases de données SQL Server.

    1. Placer les fichiers de données, les fichiers journaux et la base de données TempDB sur des disques dédiés
    2. Aligner les partitions de vos disques (Windows Server 2003 et antérieurs)
    3. Aligner le nombre de fichiers de données de vos bases de données et principalement la base de données TempDB au nombre de processeurs du serveur.
    4. Formater les disques qui hébergent les fichiers de données avec une taille de cluster adéquate (8, 16, 32 ou 64 Ko), le choix de la taille doit se faire suite à une analyse et des tests qui prendront en compte le contexte d’exploitation de votre base de données et les caractéristiques techniques de votre équipement de stockage.
    5. Favoriser les systèmes RAID 1+0 pour les disques qui hébergeront les journaux de transaction et la base de données TempDB
    6. Planifier convenablement la taille des fichiers de données, des fichiers journaux ainsi que la taille des fichiers de la base de données TempDB.