Article complet: Commutateurs /3GB et /PAE

27/01/2011

Permalink 19:30:47, Catégories: Récapitulatif SGBD, SQL Server, SQL SERVER 2005, SQL SERVER 2008, 1130 mots   French (FR) , zinzineti

[SGBD][SQL Server] Commutateurs /3GB et /PAE

L'un des objectifs principaux de tous les SGBD est de réduire les entrées/sorties (E/S) disque car les lectures et écritures sur le disque font partie des opérations les plus consommatrices de ressources. SQL Server pour atteindre cet objectif crée un pool de mémoires tampons pour garder les pages de la base de données lues en mémoire.
De façon standard les systèmes d'exploitation Microsoft Windows 32 bits peuvent adresser une mémoire maximale de 4 Go.
Dans ce cas, 2Go sont reservés pour l'OS et 2Go pour les applications. La mémoire étant un élément fondamental pour le bon fonctionnement du SGBD, comment permettre au moteur SQL de disposer d'une quantité de mémoire supérieure à 2Go sur un OS 32 bits ? Deux commutateurs permettent de résoudre ce problème afin d'allouer plus de 2Go de mémoire à SQL SERVER, il s'agit de /3GB et /PAE.

[Suite:]

/3GB permet à SQL SERVER d'utiliser une mémoire proche de 3Go.
/PAE permet à SQL SERVER d'utiliser une mémoire supérieure à 3Go.

Avant tout il faut d'abord voir s'il y a de commutateur (/3GB ou /PAE) activé sur le serveur.
--------------------------------------------------------------------------------------------

SELECT CAST(physical_memory_in_bytes as decimal) / (1024*1024*1024) AS [Mémoire Physique (Go)],

CAST(virtual_memory_in_bytes as decimal) / (1024*1024*1024) AS [Mémoire Virtuelle (Go)],

CASE

WHEN CAST(virtual_memory_in_bytes as decimal) / (1024*1024*1024) > 2 AND CAST(virtual_memory_in_bytes as decimal) / (1024*1024*1024) <=3 THEN '/3GB est activé'

WHEN CAST(virtual_memory_in_bytes as decimal) / (1024*1024*1024) > 3 AND CAST(virtual_memory_in_bytes as decimal) / (1024*1024*1024) <=64 THEN '/PAE est activé'

ELSE 'Aucun commutateur n''est activé'

END AS [Commutateur activé]

FROM sys.dm_os_sys_info

 

Quelle configuration mémoire appliquée ? 3GB ? PAE ? .
--------------------------------------------------------------------------------------------
Tout dépend de l'architecture (32 bits ou 64 bits) de votre système (OS et SQL SERVER) et de la quantité totale de mémoire disponible sur le serveur.
Pour savoir la configuration qui convient dans votre contexte référez-vous à ce billet que j'ai écrit.

--------------------------------------------------------------------------

Comment configurer le commutateur /3GB ?

--------------------------------------------------------------------------
/3GB permet à SQL SERVER d'utiliser une mémoire proche de 3Go.
Le commutateur /3GB n'est pris en charge que par les systèmes d'exploitation suivants :
• Windows 2000 Advanced Server
• Windows 2000 Datacenter Server
• Windows Server 2003 Standard Edition
• Windows Server 2003 Datacenter Edition

Le commutateur /3GB ne doit pas être utilisé avec Windows 2000 Server car il n'est pas pris en charge et peut entraîner une défaillance d'une application ou d'un système d'exploitation.

Pour configurer /3GB, ouvrir le fichier boot.ini (il se trouve sur le disque C:\)

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Standard" /noexecute=optout /fastdetect

Ajouter /3GB dans ce fichier puis enregistrer

[boot loader]

timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Standard" /noexecute=optout /fastdetect /3GB

NB : Il faut redémarrer l'OS pour mettre en service le /3GB

--------------------------------------------------------------------------

Comment configurer le commutateur /PAE ?

--------------------------------------------------------------------------
L'extension d'adresse physique /PAE (Physical Address Extension) permet à un processeur 32 bits à adresser plus de 4 Go de mémoire physique.
Les systèmes d'exploitation capables d'utiliser la fonction PAE sont:
• Microsoft Windows 2000 Advanced Server
• Microsoft Windows 2000 Datacenter Server
• Microsoft Windows Server 2003 Enterprise Edition
• Microsoft Windows Server 2003 Datacenter Edition

la configuration du /PAE se fait côté Windows (OS) et côté SQL SERVER :

Côté Windows :
1/Modifier le fichier boot.ini (ou les commmandes BCDEDIT sous Windows 2008)
2/Activer le 'Lock Pages in Memory' pour le compte de service sqlservr.exe

Côté SQL SERVER : Activer AWE (Address Windowing Extensions) et configurer le 'max server memory'

Côté Windows :
---> fichier boot.ini (généralement ce fichier est sur C:\ et est caché il faut modifier les propriétés du dossier pour qu'il soit visible)

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Standard" /noexecute=optout /fastdetect

Ajouter /PAE à ce fichier puis enrégistrer

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Standard" /noexecute=optout /fastdetect /PAE

Sous Windows 2008 la procédure est différente, il faut exécuter deux commandes BCDEDIT dans la console DOS

BCDEDIT /SET PAE ForceEnable
BCDEDIT /SET IncreaseUserVA 3072

--->Activer le 'Lock Pages in Memory' pour le compte de service sqlservr.exe
¤ Lancer la commande gpedit.msc après Démarrer > Exécuter sous Windows
Dans la fenêtre qui apparaît naviguer jusqu'à l'emplacement 'User Rights Assignment' comme le montre l'image ci-dessous

¤ Dans la fenêtre à droite, clique droit sur 'Lock Pages in Memory' puis propiétés
¤ Ajouter le compte de service sqlservr.exe puis cliquer sur le bouton OK
¤ Redémarrer le service SQL SERVER Service

Côté SQL SERVER

---> Activer AWE (Address Windowing Extensions) et configurer le 'max server memory'
L'exemple suivant montre comment activer les extensions AWE et configurer une limite de 6 Go pour l'option max server memory :

sp_configure 'show advanced options', 1

RECONFIGURE

GO

sp_configure 'awe enabled', 1

RECONFIGURE

GO

sp_configure 'max server memory', 6144

RECONFIGURE

GO 

Le gestionnaire des tâches windows (task manager) ne permet pas de savoir la quantité de mémoire utilisée par SQL SERVER via l'AWE. Pour le savoir il faut utiliser la DMV sys.dm_os_memory_clerks

SELECT sum(awe_allocated_kb)/1024 as [Quantité de mémoire allouée via AWE (Mo)]

FROM sys.dm_os_memory_clerks

Tableau d'utilisation de mémoire pour le commutateur /PAE

Operating system

Maximum memory support with PAE

Windows 2000 Advanced Server

 8 GB of physical RAM

Windows 2000 Datacenter Server

 32 GB of physical RAM

Windows XP (all versions)

 4 GB of physical RAM*

Windows Server 2003 (and SP1), Standard Edition

 4 GB of physical RAM*

Windows Server 2003, Enterprise Edition

 32 GB of physical RAM

Windows Server 2003, Datacenter Edition

 64 GB of physical RAM

Windows Server 2003 SP1, Enterprise Edition

 64 GB of physical RAM

Windows Server 2003 SP1, Datacenter Edition

 128 GB of physical RAM

  * Total physical address space is limited to 4 GB on these versions of Windows.

Avec les OS 64 bits, comment permettre à SQL SERVER de profiter au maximum de RAM sans pénaliser l'utilisation de mémoire nécessaire au bon fonctionnement de l'OS ?

La prise en charge AWE n'est disponible que dans les éditions Enterprise, Standard et Developer de SQL Server ; par ailleurs, elle ne s'applique qu'aux versions 32 bits de SQL Server. Analysis Services ne peut pas tirer profit de la mémoire mappée AWE. Si la mémoire physique disponible est moins importante que l'espace d'adressage virtuel en mode utilisateur, AWE ne peut pas être activé. (source ici)

---------------------------------------------------------------------
Etienne ZINZINDOHOUE
---------------------------------------------------------------------

Social Bookmarking:

                                     

Commentaires:

Connectez-vous pour vous abonner à cet article:

Flux de commentaires pour cet article : Atom 1.0  RSS 2.0
Commentaire de: mikedavem [Membre] · http://mikedavem.developpez.com/
Lut,

Petite correction :

/PAE permet à SQL SERVER d'utiliser une mémoire supérieure à 3Go --> c'est 4Go

Peut être à ajouter l'utilisation de l'option USERVA qui permet de configurer plus finement l'espace réservé au kernel (http://blog.developpez.com/mikedavem/p8369/sql-server-2005/architecture/fonctionnement-et-utilisation-des-option/)

A+
Permalien 27/01/2011 @ 19:47
Commentaire de: zinzineti [Membre]
/PAE permet à une architecture 32 bits de prendre en charge plus de 4 Go de mémoire. Dans ce cas SQL SERVER peut donc utiliser une mémoire supérieure à 3 Go. Avec /3GB la valeur maximale de mémoire utilisée par SQL SERVRER est 3Go.
Tu vois le raisonnement ? au fait je focuse sur la mémoire utulisée par SQL SERVER, pas sur la mémoire utilisée par l'architecture (la machine 32 bits) ;-)

A propos de l'option USERVA, je ferai mes commentaires sur ton blog ;-)

A+


Permalien 27/01/2011 @ 23:14
Commentaire de: Jinroh77 [Membre]
Bonjour,
Merci pour ce billet complet, notamment avec les précisions sur Windows Server 2008 :)

Par contre je rencontre un problème sur un serveur (Win 2008, SQL 2008R2, tout en x86, 8Go) pour lequel, bien que "bcdedit /enum" m'indique "pae : ForceEnable", la commande est donc bien activée, après un reboot, le script du début du billet me retourne que seul /3GB est activé. Aucune trace du /PAE...
Le compte de service est bien dans le lock page..., l'AWE est bien activé sur mon instance qui a elle aussi redémarrée.
Je ne vois donc pas comment la mémoire virtuelle se limite à 3 Go :(



Permalien 15/11/2011 @ 17:16

Vous devez être identifié pour poster un commentaire.

Liste des blogs

SQL SERVER - Etienne ZINZINDOHOUE

Etienne ZINZINDOHOUE SQL SERVER

Etienne ZINZINDOHOUE

Rechercher

<  Mai 2012  >
Lun Mar Mer Jeu Ven Sam Dim
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Liens

SQL SERVER 2005

  • [SGBD][SQL Server] Active Directory - SQL SERVER

    Il est possible d'utiliser l'Active Directory (AD) comme source de données, pour mettre à jour des tables d'une base de données SQL SERVER. Les tables en question peuvent contenir des informations relatives aux :
    ¤ employés
    ¤ ordinateurs d'une entreprise (ou d'une organisation)
    ¤ ...
    Dans ce billet nous allons voir comment utiliser l'AD comme source pour mettre à jour une table de la base de données.
    ]suite

    Permalien
  • [SGBD][SQL Server] Afficher les principales options de configuration des bases d'une instance

    Avant toute opération d'optimisation d'une base de données, il est indispensable de vérifier rapidement les options automatiques de configuration de la base. Les incontournables :

    --> AUTO_SHRINK = OFF
    --> AUTO_CREATE_STATISTICS = ON
    --> AUTO_UPDATE_STATISTICS = ON
    --> AUTO_UPDATE_STATISTICS_ASYNC = OFF
    ]suite

    Permalien
  • [SGBD][SQL Server] Audit cache de procédures

    Quelques requêtes pour auditer le cache de procédures
    ]suite

    Permalien
  • [SGBD][SQL Server] AUDIT DES INDEX

    S'il est vrai que les index (les bons) participent à l'amélioration des performances d'une base de données,il ne faut pas perdre de vue que sa maintenance à un coût et donc pénalisant pour la performance. Alors comment trouver, au profit de la performance, le juste milieu ?. Voici une série de requêtes qui permettent de :
    --> Afficher le nombre d'index manquants par base sur une instance
    --> Afficher les index manquants et leur bénéfice
    --> Afficher le coût des index non utilisés pour décider de leur suppression ou pas.
    --> Mettre en perspective les index utilisés et leur coût de maintenance
    ]suite

    Permalien
  • [SGBD][SQL Server] BASCULER TOUTES LES BASES UTILISATEURS EN MODE DE RECUPERATION FULL

    Si en toute connaissance de cause vous décidez de basculer toutes les bases de données utilisateurs d'une instance SQL Server (2005 ou 2008) en mode de récupération FULL alors ce script peut vous éviter de perdre du temps à faire une tâche répétitive...
    ]suite

    Permalien
  • [SGBD][SQL Server] CHAR ou VARCHAR ?

    Pour écconomiser de l'espace de stockage des données des tables, on est souvent confronté au choix du type CHAR ou VARCHAR.
    Pour une colonne dont la longueur est fixe, il n'y a pas de doute sur le choix du type de colonne : c'est CHAR qu'il faut utiliser. Mais lorsque la longueur de la colonne est variable, il faut se poser la question du choix du type de colonne. Ce n'est pas parce que les données dans la colonne varie qu'il faut systématiquement choisir le type VARCHAR.
    Si la longueur de la colonne varie et est majoritairement supérieure à 4 caractères, il faut choisir le type VARCHAR.
    Autrement dit même si la colonne est variable et si la longueur des données est majoritairement inférieure ou égale à 4 caractères il faut choisir le type CHAR. ]suite

    Permalien
  • [SGBD][SQL Server] Clean And Check PhoneNumber

    Dans les "Call Centers", une phase importante de la préparation d'une campagne d'appels sortant (Outbound calls) consiste à passer la table d'appels et plus précisément la colonne "Numéro de téléphone" dans une moulinette afin d'avoir des numéros de téléphones valides. Si la table d'appels contient un nombre important de faux numéros c'est sûr que la campagne ne sera pas fructueuse.
    Voici une fonction SQL qui permet de nettoyer et de valider les numéros de téléphones.

    ]suite

    Permalien
  • [SGBD][SQL Server] Commutateurs /3GB et /PAE

    L'un des objectifs principaux de tous les SGBD est de réduire les entrées/sorties (E/S) disque car les lectures et écritures sur le disque font partie des opérations les plus consommatrices de ressources. SQL Server pour atteindre cet objectif crée un pool de mémoires tampons pour garder les pages de la base de données lues en mémoire.
    De façon standard les systèmes d'exploitation Microsoft Windows 32 bits peuvent adresser une mémoire maximale de 4 Go.
    Dans ce cas, 2Go sont reservés pour l'OS et 2Go pour les applications. La mémoire étant un élément fondamental pour le bon fonctionnement du SGBD, comment permettre au moteur SQL de disposer d'une quantité de mémoire supérieure à 2Go sur un OS 32 bits ? Deux commutateurs permettent de résoudre ce problème afin d'allouer plus de 2Go de mémoire à SQL SERVER, il s'agit de /3GB et /PAE.
    ]suite

    Permalien
  • [SGBD][SQL Server] Configuration CPU - SQL SERVER

    Le nombre et le type de processeur influencent la performance d'un serveur. Une fois le serveur SQL mis en place, il est généralement difficile de décider après de changer de type de CPU ou d'en augmenter le nombre; comme on peut le faire avec les autres composants matériel de la machine : mémoire ou disque dur. En cas de dégradation des performances liées à l'utilisation de CPU que faut-il faire ?
    Quatre approches de solution :

    ¤ Checkup des options avancées relatives à la configuration du CPU.
    ¤ Identifier et optimiser les requêtes les plus consommatrices de CPU : Reécriture des requêtes, création des bons index,..(En général, pour une base de données en production il n'est plus possible de modifier le model de données)

    ¤ Tester l'effet (ON/OFF) de l'Hyperthreading. L'option ON/OFF de l'Hyperthreading se modifie dans le BIOS.
    ¤ Envisager la mise en place du "gouverneur de ressources" (introduit depuis SQL SERVER 2008) pour répartir des ressources mémoires et CPU selon la charge de travail.

    ]suite

    Permalien
  • [SGBD][SQL Server] DATETIME : What You See Is Not What Is Stored

    SQL SERVER 2008 dispose de six types pour stocker les données date/heure :
    ¤ DATETIME
    ¤ SMALLDATETIME
    ¤ DATE
    ¤ TIME
    ¤ DATETIME2
    ¤ DATETIMEOFFSET

    Les types DATETIME,SMALLDATETIME sont disponibles depuis les premières versions de SQL SERVER.
    Par contre les types DATE,TIME,DATETIME2,DATETIMEOFFSET sont disponibles qu'à partir de SQL SERVER 2008.

    ¤ Pour le type DATETIME (stocké sur 8 octets) la date (date de référence 1er janvier 1900) est stockée sur 4 octets
    et l'heure (en clock-ticks) est stockée sur 4 octets.

    ¤ Pour le type SMALLDATETIME (stocké sur 4 octets) la date (date de référence 1er janvier 1900) est stockée sur 2 octets
    et l'heure (en minute pas en clock-ticks comme dans datetime) est stockée sur 2 octets.

    ¤ Pour le type DATETIME2 les choses ne sont pas simples, car :
    • la date de référence est le 1 janvier 0001
    • l'heure (en secondes) est stockée sur un nombre d'octets variable selon la précision

    Examinons en détails comment SQL SERVER gère les types DATETIME
    ]suite

    Permalien
  • [SGBD][SQL Server] déplacer/copier/supprimer un fichier de données

    Lorsqu'on met en place un automate d'import/export de fichier (fichier de campagne d'appels sortants par exemple), on a besoin de :
    --> tester l'existence du fichier d'import/export
    --> faire l'opération d'import/export (pour ça j'utilise l'utilitaire BCP)
    --> déplacer/copier/supprimer/renommer le fichier dans le repertoire d'archivage

    Voici des procédures stockées qui permettent de déplacer/copier/supprimer ces fichiers de données à l'aide du T-SQL.

    ]suite

    Permalien
  • [SGBD][SQL Server] Identifier les login/password non sécurisés

    Identifier les login/password non sécurisés
    ]suite

    Permalien
  • [SGBD][SQL Server] Index non-cluster : choix de l'optimiseur

    L'idée est d'examiner l'utilisation des index non-cluster par l'optimiseur de requête.
    Afin de mettre en évidence le choix du moteur de base données vis à vis des index non-cluster couvrants avec colonnes incluses ou non
    ]suite

    Permalien
  • [SGBD][SQL Server] Index non-cluster : Tipping point ou Zone de basculement

    Le "Tipping point" qu'on peut traduire littérallement par point de basculement, correspond à la situation où un index non cluster n'est pas utilisé par l'optimiseur dans le cas d'une requête SARGable. Je préfère utiliser le terme Zone (ou ligne) de basculement que le terme "point de basculement" (Tipping point) parce qu'il me semble que la notion de point n'existe pas dans une base de données !
    En mathématique, le point de basculement existe. Par exemple lorsqu'on étudie une fonction de second dégré qui est sous la forme de f(x) = ax² + bx + c, on se rend compte que cette fonction possède un point particulier appelé EXTREMUM. Ce dernier apparaît lorsque la dérivée première de la fonction s'annule et change de signe. Là il s'agit bien d'un POINT de basculement!
    Le même phénomène peut être mis en évidence en Physique, lorsqu'on s'interesse à l'étude des trajectoires paraboliques. L'exemple le plus simple dans ce cas est l'étude de la trajectoire d'une balle de basket lorsqu'un joueur fait un tir à 3 points. La trajectoire décrite par la balle est telle que lors du lancement, elle monte, atteint une hauteur maximale puis redescend dans le panier (si le tir est bon !). L'instant où la balle atteint une hauteur maximale (encore appelé flêche) est un POINT de basculement.
    Mais en base de données il n'existe pas de POINT ! il existe des lignes (suite de colonnes).

    Pour revenir à la zone de basculement dans la cas d'une base de données, Kimberly L. Tripp a publié un article sur le sujet.
    Elle a présenté une méthode théorique d'ESTIMATION de cette zone rouge. Disons-le tout de suite, ce n'est qu'une estimation car beaucoup de paramètres peuvent influencer cette zone. La seule façon de savoir si l'optimiseur n'utilsera pas un index non cluster c'est de faire le test et analyser le plan d'exécution.

    Voici néanmoins une requête qui permet d'obtenir pour chaque table d'une base de données les limites théoriques de la zone de basculement
    ]suite

    Permalien
  • [SGBD][SQL Server] Index sur colonne calculée ou vue indexée

    Quels sont les conditions pour créer un index sur une colonne calculée ou une vue ?
    Voici un scénario pour mettre en évidence les pré-réquis.
    ]suite

    Permalien
  • [SGBD][SQL Server] index sur une colonne non déterministe ?

    Peut-on créer un index sur une colonne non déterministe ?
    Qu'est ce qu'une colonne déterministe ou non ? comment les identifier ?
    ]suite

    Permalien
  • [SGBD][SQL Server] Indicateurs de performances : Temps CPU (moins fiable) et le nombre de pages logiques lues

    Généralement le temps CPU et le nombre de pages logiques lues sont les indicateurs de performance d'une requête.
    Pour obtenir les valeurs de ces indicateurs SQL Server met à disposition les commandes :
    SET STATISTICS IO ON  
    SET STATISTICS TIME ON

    Ces commandes fournissent beaucoup d'informations et donc engendrent des fois une perte de temps. Par exemple si on travaille sous SSMS (SQL Server Management Studio), les résultats de la requête sont présentés dans l'onglet "Résultats" et les indicateurs de performances dans l'onglet "Messages". Et il y en a un paquet alors que la plupart du temps c'est le nombre de pages logiques lues qui est l'indicateur le plus fiable car le temps CPU varie de façon aléatoire pour une même requête et pour une même base dont l'état n'a pas changé !
    ]suite

    Permalien
  • [SGBD][SQL Server] Informations sur les requêtes

    Quelles sont les requêtes les plus consommatrices de CPU sur une instance SQL Server?

    Quelles sont les dernières requêtes exécutées sur une instance SQL Server ?

    Quelles sont les requêtes les + fréquemment exécutées sur une instance SQL Server ?
    ]suite

    Permalien
  • [SGBD][SQL Server] Intégrité référentielle - Performance des requêtes

    L'intégrité référentielle ou contrainte de clé étrangère (CONSTRAINT FOREIGN KEY) permet de contrôler la validité, la cohérence et la consistance des données dans une base. Ce mécanisme assure donc une meilleure qualité des données. Elle met également en exergue les liens entre les tables et permet ainsi d'avoir une bonne visibilité de la structure de la base de données. À travers des exemples simples [mais pas choisit au hazard ;-)], nous allons examiner l'impact de l'intégrité référentielle sur la performance des requêtes. Cette analyse va nous conduire à mettre en évidence les situations où on peut être amené à désactiver/activer la contrainte de clé étrangère afin d'optimiser la performance des requêtes.
    ]suite

    Permalien
  • [SGBD][SQL Server] ISO_WEEK

    L'option ISO_WEEK pour la fonction DATEPART n'existe pas sous SQL SERVER 2005. Sous SQL SERVER 2008 et > Cette option retourne le numéro de semaine pour une date, telle que définie par la norme ISO 8601.
    La norme ISO pour la numérotation des semaines impose que :
    --> la semaine numéro 1 d'une année correspond à la semaine où tombe le premier jeudi de l'année.
    --> la semaine commence le lundi

    Cette norme ISO est conforme aux calendriers actuels utilisés dans la plupart des pays européens et africains (certains africains attachés aux rapports directs avec la nature continuent de prendre comme référence du début du mois, l'apparition du croissant de lune ...)

    Voyons concrètement le mécanisme de numérotation ISO pour la semaine et son impact sous SQL SERVER]suite

    Permalien

Syndiquez ce blog XML

Articles :

Commentaires :

 
 
 
 
Partenaires

Hébergement Web