Forum aux questions sur SQLHeure d’été, mémoire de serveur et plus

Par Nancy Michell

Heure d’été

Q Étant donnés les changements à venir en ce qui concerne l’heure d’été aux États-Unis pour se conformer à l’Energy Policy Act de 2005, dois-je mettre à jour SQL Server™ ?

R Non. Aucune mise à jour de SQL Server n’est à l’heure actuelle nécessaire pour la prise en charge de la modification de l’heure d’été. SQL Server repose sur le système d’exploitation sous-jacent en ce qui concerne les données liées à l’heure d’été, ce qui signifie que si le système d’exploitation fournit des dates et heures correctes, SQL Server fournira et utilisera des valeurs identiques. Pour vous conformer aux modifications à venir concernant l’heure d’été, vous devrez mettre à jour votre exemplaire de Windows® comme indiqué sur support.microsoft.com/kb/928388. Ceci sera nécessaire sur tous les systèmes d’exploitation Windows précédant Windows Vista™ (qui inclut déjà ces modifications) pour se conformer aux modifications de l’heure d’été, y compris ceux qui exécutent SQL Server. L’Australie fait également l’objet de quelques modifications. Voir support.microsoft.com/kb/912475.

Connexion avec Windows Vista

Q j’ai installé Windows Vista et maintenant je ne peux pas me connecter à SQL Server 2005 depuis mon système. Je suis administrateur local et je pouvais habituellement me connecter sans problème. Que s’est-il passé ?

R Il s’agit du comportement normal avec Windows Vista et SQL Server 2005 sans Service Pack 2 (SP2). Windows Vista possède un nouveau modèle de sécurité (Contrôle de compte d’utilisateur) qui a pour effet de limiter votre appartenance au groupe des administrateurs locaux et de vous demander de confirmer les opérations nécessitant des privilèges d’administrateur. Si vous cliquez sur le bouton Autoriser, vos informations d’authentification, qui incluent votre jeton d’administrateur, sont transférées à l’application. Avec SQL Server Management Studio (SSMS), aucune boîte de dialogue n’est affichée car l’exécution seule de l’outil ne nécessite pas d’autorisations administratives. Le problème est que par défaut le rôle d’administrateur SQL Server 2005 inclut le groupe d’administrateurs locaux du système d’exploitation et c’est ce que votre compte utilisait dans le passé pour accéder à SQL Server. Puisque Windows Vista ne transfère pas cette autorisation, l’accès ne vous est pas accordé.

Notez cependant que l’exécution de SQL Server 2005 sans SP2 n’est pas prise en charge sur Windows Vista et que SP2 dispose d’un outil qui ajoutera votre compte pour vous. Si vous attendez toujours pour installer SP2, la solution est assez simple. Votre compte d’utilisateur individuel de Windows doit être ajouté à SQL Server, dans votre cas au rôle d’administrateur système. Pour ce faire, cliquez simplement avec le bouton droit sur SQL Server Management Studio et sélectionnez Exécuter en tant qu’administrateur. Connectez-vous à votre serveur SQL Server et ajoutez votre compte Windows au rôle d’administrateur système. Reportez-vous à SQL Server Books Online pour plus d’informations sur cette manipulation.

Réplication transactionnelle avec les vues

Q Si je dispose d’une vue publiée et que je la mets à jour, je sais que cette transaction sera répliquée. Si je mets toutefois à jour la table de base de cette vue, cette transaction sera-t-elle répliquée ? Par ailleurs, si j’ai une table publiée, que je crée une vue pour celle-ci et que je mets à jour la vue au lieu de la table de base, cette transaction sera-t-elle répliquée ?

R En supposant que la table de base est configurée comme article d’une publication (c’est-à-dire que vous avez également configuré la table de base pour la réplication), toute mise à jour de la table de base est alors répliquée.

Lorsque vous répliquez une vue, par défaut, tout ce qui est répliqué dans la vue se compose de la partie schéma de cette vue, ou du code de la vue, et non des données sous-jacentes (sauf en cas de vue indexée). Ensuite, même sans réplication, toute mise à jour d’une vue (ce qui revient dans ce cas à exécuter une instruction du langage de manipulation de données [DML] avec la vue comme cible) est uniquement une mise à jour des données de la table sous-jacente et non de la vue. Une vue est uniquement un stockage logique d’une instruction de requête à laquelle aucun stockage physique n’est associé (sauf, ici encore, s’il s’agit d’une vue indexée).

Mémoire de serveur maximale

Q J’ai un ordinateur exécutant Windows Server® 2003 et SQL Server 2000, avec 5 Go de RAM. Disons que j’utilise le commutateur /3GB pour augmenter mon espace d’adressage virtuel en mode utilisateur, le commutateur /PAE pour charger la version d’extension d’adresse physique (Physical Address Extension, PAE) du noyau de Windows et que j’active Address Windowing Extensions (AWE) en le définissant sur 1 (et active le verrouillage des pages en mémoire). Avec AWE activé, est-ce que l’option de mémoire maximale de serveur configurera uniquement la taille de la mémoire cache des données ou la taille de toutes les mémoires cache de tampons (données, processus, sessions, etc.) ? Puisque seule la mémoire cache de données peut tirer parti de la mémoire mappée par AWE, si je configure la mémoire de serveur maximale sur 4 Go, est-ce que la mémoire cache de données utilisera seulement 1 Go (la portion mappée par AWE) ou pourra-t-elle utiliser ce gigaoctet supplémentaire et continuer à utiliser l’espace d’adressage standard ou à entrer en compétition avec les autres consommateurs de mémoire pour l’accès à celui-ci ?

R La mémoire maximale de serveur limitera toujours la taille complète du pool de tampons, même si seule la mémoire cache de données peut accéder à la mémoire mappée par AWE.

Donc pour répondre à votre première question, même avec AWE activé, la mémoire de serveur maximale limite toujours le pool complet de tampons, mais les consommateurs différents de la mémoire cache de données n’utiliseront jamais la mémoire mappée par AWE.

Pour répondre à la deuxième question, la mémoire cache de données utilisera la mémoire mappée par AWE, plus toute autre mémoire du pool de tampons que SQL Server qualifie comme appropriée. Il ne sera pas uniquement limité à la mémoire AWE mais sera le seul consommateur pouvant tirer parti de la mémoire AWE. Si vous n’êtes pas certain de l’effet du commutateur /3GB, consultez le blog de Raymond Chen (en anglais).

Profilage et performances

Q Je dispose de SQL Server 2005 mis en miroir dans un environnement de production. Lorsque je démarre SQL Server Profiler sur l’ordinateur de la base de données et que j’écris les données de suivi dans un fichier, j’observe une chute importante des performances. Pourquoi ?

R La raison de la chute des performances dépend de l’emplacement depuis lequel Profiler est exécuté. Si vous l’exécutez de manière interactive sur l’ordinateur serveur, l’interface utilisateur du Profiler consomme mémoire et processeur sur le serveur, ce qui a des répercussions sur les performances.

Si vous exécutez Profiler de manière interactive sur un poste de travail, vous déplacez alors les informations concernant les événements sur le réseau. Ceci a des répercussions sur le débit. S’il s’agit du réseau que vous utilisez également pour la mise en miroir, vous pourrez également constater l’impact sur ce dernier. En outre, si vous enregistrez le résultat de Profiler sur un partage réseau, vous déplacez des données sur le réseau et avez un impact négatif sur les performances.

La meilleure manière de concilier tout ceci est probablement d’exécuter Profiler de manière non interactive sur le serveur qui exécute l’instance dont le profilage doit être effectué et de rediriger la sortie vers un fichier local. Vous consommerez toujours des ressources du serveur, mais cette approche a généralement l’impact le plus réduit. Ceci fonctionne beaucoup mieux que le suivi de profilage en mémoire. Le suivi dans un fichier utilise la mémoire système plus efficacement. Il dispose de plus grands tampons et les vide sur disque plus efficacement. Il ne dépend pas non plus de processus externes (tels que SQL Server Profiler).

Enfin, les données de suivi sont écrites dans un fichier sur disque pendant que le Profileur continue à effectuer le profilage. Le fichier de suivi est partagé afin que d’autres personnes puissent voir à distance les données de profil en temps réel. Si vous appelez le fichier de suivi de manière interactive, cela signifie que vous avez invoqué Profiler manuellement et que vous affichez le résultat à l’écran. Les suivis peuvent être créés par programmation sans résultat visuel, ce qui explique pourquoi ces opérations doivent être effectuées sans aucune interaction.

Vous pouvez créer un partage avec un répertoire local et d’autres personnes peuvent accéder aux fichiers qui s’y trouvent, ce qui fonctionne en général bien. Comme indiqué auparavant, il n’est pas souhaitable d’envoyer le résultat du suivi vers un partage distant, en particulier si l’accès à celui-ci a lieu sur le même canal de réseau que celui utilisé pour la mise en miroir.

Vous devez également sélectionner uniquement l’ensemble d’événements nécessaire à votre investigation. Pour l’emplacement du fichier de suivi, vous devez choisir le lecteur le plus rapide sur votre système (de préférence différent des lecteurs de la base de données et du journal des transactions SQL Server). Si vous constatez toujours une dégradation significative des performances, fractionnez les événements en deux suivis ou plus, ciblant chacun un disque dur différent. Même si les suivis ciblent le même disque dur, cette division vous offrira toujours des avantages, car chaque suivi dispose de son propre ensemble de tampons. Pour plus d’informations, reportez-vous à sp_ trace_create et à tous ses éléments liés dans SQL Server Books Online (en anglais).

Problèmes de clusters

Q J’essaie d’installer SQL Server sur un cluster utilisant Windows Server 2003. Chaque fois que j’essaie ceci, j’obtiens une erreur indiquant « Le programme d’installation n’a pas réussi à effectuer les opérations requises sur les nœuds de clusters. ». Le journal sqlstp indique simplement :

Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...

Que peut-il bien se passer ?

R Il y a plusieurs raisons possibles à cet échec. Le programme d’installation installe le service Windows NT® sur tous les nœuds sélectionnés pour la gestion à distance du processus d’installation sur les ordinateurs individuels. Donc, vous devez vous préparer à plusieurs embûches.

Tout d’abord, les utilisateurs de votre domaine peuvent avoir une stratégie de groupe qui refuse l’autorisation « d’ouverture de session en tant que service ». (Souvenez-vous que la stratégie de domaine a priorité sur votre stratégie d’ordinateur locale.) Assurez-vous que vous utilisez un compte sans ces restrictions.

Deuxièmement, le compte ayant ouvert la session sur l’ordinateur depuis lequel vous exécutez l’installation doit posséder l’accès en tant qu’administrateur à tous les nœuds pour les raisons suivantes : Le processus d’installation maître nécessite l’accès distant au registre de tous les ordinateurs ; le programme d’installation copie cnvsvc.exe vers le répertoire Windows de l’ordinateur distant ; ou le programme d’installation utilise les API Windows standard qui utilisent uniquement les autorisations du compte ayant ouvert la session pour accéder aux ordinateurs distants. Pour ces raisons, vous devriez ouvrir votre session en tant qu’administrateur pour tous les modes par défaut.

Plan de récupération après incident

Q Je me demande si je devrais utiliser la mise en miroir de base de données (en mode asynchrone) ou l’envoi de journaux pour mettre en place la stratégie de récupération après incident de mes bases de données SAP. Mes sites de production et de récupération après incident disposeront d’une connexion large bande 100 Mbits qui n’est pas dédiée à la session en miroir. La connexion sera partagée avec différentes sessions en miroir ou même d’autres serveurs de récupération après incident.

S’il y a un problème de réseau empêchant l’enregistrement de journal d’être envoyé à la base de données en miroir, y aura-t-il une nouvelle tentative ?

Lorsque la session mise en miroir est interrompue, y a-t-il une période de rétention ? Et, outre les vues du système, y a-t-il des informations de journalisation que je peux utiliser pour surveiller le trafic de mise en miroir et la transmission des enregistrements de journaux ?

R Commençons par répondre à la question suivante : Quelle est la logique de nouvelle tentative de la mise en miroir de base de données ? Vous pouvez considérer ceci de deux points de vue : Tout d’abord, s’il y a un problème de réseau passager, l’état de session en miroir est déconnecté. La valeur du délai d’expiration par défaut du réseau est 10 secondes, ce qui signifie qu’un enregistrement de journal ne peut pas être envoyé de la base de données principale à la base de données en miroir. Dans de tels cas, la base de données principale continuera à s’exécuter « exposée » et la transaction sera validée côté client. Une fois le problème de réseau résolu, la session en miroir effectuera automatiquement une nouvelle tentative, sans intervention de utilisateur. Elle tentera de rattraper le retard en utilisant les enregistrements de journaux ; les partenaires se synchroniseront d’abord et, une fois qu’ils auront rattrapé le retard, l’état sera synchronisé.

Deuxièmement, s’il y a un problème de nouvelle tentative, l’état de session en miroir est suspendu. Un problème de nouvelle tentative signifie que la base de données en miroir ne peut pas valider les enregistrements de journaux dans sa base de données. Les problèmes de nouvelle tentative sont principalement provoqués par des fichiers physiques introuvables ou un espace disque insuffisant. Dans de tels cas, la base de données principale continuera à s’exécuter exposée et la transaction sera validée côté client. Après avoir résolu manuellement le problème de nouvelle tentative sur le serveur en miroir, la session en miroir nécessite une intervention :

ALTER DATABASE <db> SET PARTNER RESUME; 

En ce qui concerne les périodes de rétention, la réponse est qu’indépendamment du fait que la session de miroir est déconnectée ou interrompue, les enregistrements de journaux seront gardés jusqu’à ce que la session soit restaurée et tous les enregistrements depuis l’heure à laquelle la session a été interrompue jusqu’à l’heure à laquelle elle a été reprise sont validés sur le miroir. En gros, pendant que la session en miroir est déconnectée ou interrompue, le journal sur la base de données principale ne peut pas être tronqué, car cela briserait à nouveau la chaîne de nouvelle tentative. Ceci signifie que le journal de la base de données principale grandira sans limites jusqu’à ce que la session soit restaurée. Donc, il n’y a en fait aucune limite de rétention pour la session en miroir. La seule véritable contrainte est l’espace disque dont le serveur principal dispose pour enregistrer le journal, puisque celui-ci ne peut pas être tronqué.

Enfin, il n’existe aucun fichier journal spécifique pouvant être utilisé pour surveiller la mise en miroir. SQL Server 2005 dispose d’un outil à interface utilisateur graphique appelé Database Mirroring Monitor, qui permet aux administrateurs système d’afficher et de mettre à jour l’état et de configurer les seuils d’avertissement de plusieurs mesures de performances clés. Grâce à ceci, vous pouvez obtenir une alerte lorsque la mise en miroir ne fonctionne pas bien. Le souci de performances principal avec la mise en miroir de base de données est le traitement en temps voulu des enregistrements des journaux. Pour plus d’informations sur la surveillance des bases de données en miroir, consultez l’article (en anglais) concernant la surveillance de l’état de la mise en miroir sur msdn2.microsoft.com/fr-fr/library/ms365781.aspx.

Merci aux informaticiens Microsoft ci-dessous pour leur expertise technique : Chad Boyd, Sandu Chirica, Alan Doby, Kaloian Manassiev, Luciano Moreira, Ivan Penkov, Sivagaminathan Rajarethinam, Deborah To, Patrick Woodward, Buck Woody, Stanley Yau et Warren Young.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.