Quelle est la taille de cluster disque préconisée pour héberger les fichiers de données d'une base transactionnelle SQL Server 7
Quelles sont vos expériences à ce sujet
(J'ai de gros problèmes de performance avec un ERP tournant sur SQL Server 7, et j'évalue tous les paramètres pour améliorer la situation)
Merci.
Les pages de données de SQL Server dont fixes et de 8 ko. Essaye donc un cluster de ce volume ! es tu en raid ? si oui, combien de disque ?? quelle organisation de fichiers ???
A +
Westmont a écrit:
Quelle est la taille de cluster disque préconisée pour héberger les fichiers de données d'une base transactionnelle SQL Server 7 ? Quelles sont vos expériences à ce sujet ? (J'ai de gros problèmes de performance avec un ERP tournant sur SQL Server 7, et j'évalue tous les paramètres pour améliorer la situation). Merci.
-- Frédéric BROUARD, MVP MS SQL Server. Expert Langage SQL / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Les pages de données de SQL Server dont fixes et de 8 ko.
Essaye donc un cluster de ce volume !
es tu en raid ?
si oui, combien de disque ??
quelle organisation de fichiers ???
A +
Westmont a écrit:
Quelle est la taille de cluster disque préconisée pour héberger les fichiers de données d'une base transactionnelle SQL Server 7 ?
Quelles sont vos expériences à ce sujet ?
(J'ai de gros problèmes de performance avec un ERP tournant sur SQL Server 7, et j'évalue tous les paramètres pour améliorer la situation).
Merci.
--
Frédéric BROUARD, MVP MS SQL Server. Expert Langage SQL / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Les pages de données de SQL Server dont fixes et de 8 ko. Essaye donc un cluster de ce volume ! es tu en raid ? si oui, combien de disque ?? quelle organisation de fichiers ???
A +
Westmont a écrit:
Quelle est la taille de cluster disque préconisée pour héberger les fichiers de données d'une base transactionnelle SQL Server 7 ? Quelles sont vos expériences à ce sujet ? (J'ai de gros problèmes de performance avec un ERP tournant sur SQL Server 7, et j'évalue tous les paramètres pour améliorer la situation). Merci.
-- Frédéric BROUARD, MVP MS SQL Server. Expert Langage SQL / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Fred BROUARD
Les pages de données de SQL Server dont fixes et de 8 ko. Essaye donc un cluster de ce volume ! es tu en raid ? si oui, combien de disque ?? quelle organisation de fichiers ???
A +
Westmont a écrit:
Quelle est la taille de cluster disque préconisée pour héberger les fichiers de données d'une base transactionnelle SQL Server 7 ? Quelles sont vos expériences à ce sujet ? (J'ai de gros problèmes de performance avec un ERP tournant sur SQL Server 7, et j'évalue tous les paramètres pour améliorer la situation). Merci.
-- Frédéric BROUARD, MVP MS SQL Server. Expert Langage SQL / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Les pages de données de SQL Server dont fixes et de 8 ko.
Essaye donc un cluster de ce volume !
es tu en raid ?
si oui, combien de disque ??
quelle organisation de fichiers ???
A +
Westmont a écrit:
Quelle est la taille de cluster disque préconisée pour héberger les fichiers de données d'une base transactionnelle SQL Server 7 ?
Quelles sont vos expériences à ce sujet ?
(J'ai de gros problèmes de performance avec un ERP tournant sur SQL Server 7, et j'évalue tous les paramètres pour améliorer la situation).
Merci.
--
Frédéric BROUARD, MVP MS SQL Server. Expert Langage SQL / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Les pages de données de SQL Server dont fixes et de 8 ko. Essaye donc un cluster de ce volume ! es tu en raid ? si oui, combien de disque ?? quelle organisation de fichiers ???
A +
Westmont a écrit:
Quelle est la taille de cluster disque préconisée pour héberger les fichiers de données d'une base transactionnelle SQL Server 7 ? Quelles sont vos expériences à ce sujet ? (J'ai de gros problèmes de performance avec un ERP tournant sur SQL Server 7, et j'évalue tous les paramètres pour améliorer la situation). Merci.
-- Frédéric BROUARD, MVP MS SQL Server. Expert Langage SQL / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Med Bouchenafa
64ko est plus recommandé. Mais le mieux encore est de tester avec un outil comme celui-ci http://www.microsoft.com/downloads/details.aspx?FamilyIDš8b005b-84e4-4f24-8d65-cb53442d9e19&DisplayLang=en
Pourquoi ne pas envisager de passer en 2000 ?
-- Bien cordialement Med Bouchenafa
"Westmont" a écrit dans le message de news:
Le système de fichier est hébergé par un groupe de 4 disques configuré en RAID 5. Par défaut le contrôleur opte pour des bandes de 8 ko. Il possède un cache embarqué (32 Mo), mais
j'hésite fortement à passer en mode d'écriture différée.
Les bases de données (data) sont mono fichier, et j'ai l'intention d'attribuer une partition pour
chaque fichier de base (un seul objet donc par partition) afin d'éviter toute fragmentation du FS.
Les journaux seront hébergés par un autre groupe de disque configuré en RAID 1, la base TempDB
sera également sur ce groupe sur sa propre partition toujours pour éviter un fragmentation.
Ta réponse de 8ko me paraît tout à fait logique, mais je me demandais si opter pour une taille de
cluster plus importante (de 64ko par ex.) ne pouvait pas booster les performances.
Par ailleurs, penses tu qu'affiner la valeur max async IO peut être bénéfique en terme de
performances ?
Merci de ton intérêt.
64ko est plus recommandé.
Mais le mieux encore est de tester avec un outil comme celui-ci
http://www.microsoft.com/downloads/details.aspx?FamilyIDš8b005b-84e4-4f24-8d65-cb53442d9e19&DisplayLang=en
Pourquoi ne pas envisager de passer en 2000 ?
--
Bien cordialement
Med Bouchenafa
"Westmont" <anonymous@discussions.microsoft.com> a écrit dans le message de news:
3041507F-280B-4DE8-85E0-6536E0CA9326@microsoft.com...
Le système de fichier est hébergé par un groupe de 4 disques configuré en RAID 5.
Par défaut le contrôleur opte pour des bandes de 8 ko. Il possède un cache embarqué (32 Mo), mais
j'hésite fortement à passer en mode d'écriture différée.
Les bases de données (data) sont mono fichier, et j'ai l'intention d'attribuer une partition pour
chaque fichier de base (un seul objet donc par partition) afin d'éviter toute fragmentation du FS.
Les journaux seront hébergés par un autre groupe de disque configuré en RAID 1, la base TempDB
sera également sur ce groupe sur sa propre partition toujours pour éviter un fragmentation.
Ta réponse de 8ko me paraît tout à fait logique, mais je me demandais si opter pour une taille de
cluster plus importante (de 64ko par ex.) ne pouvait pas booster les performances.
Par ailleurs, penses tu qu'affiner la valeur max async IO peut être bénéfique en terme de
64ko est plus recommandé. Mais le mieux encore est de tester avec un outil comme celui-ci http://www.microsoft.com/downloads/details.aspx?FamilyIDš8b005b-84e4-4f24-8d65-cb53442d9e19&DisplayLang=en
Pourquoi ne pas envisager de passer en 2000 ?
-- Bien cordialement Med Bouchenafa
"Westmont" a écrit dans le message de news:
Le système de fichier est hébergé par un groupe de 4 disques configuré en RAID 5. Par défaut le contrôleur opte pour des bandes de 8 ko. Il possède un cache embarqué (32 Mo), mais
j'hésite fortement à passer en mode d'écriture différée.
Les bases de données (data) sont mono fichier, et j'ai l'intention d'attribuer une partition pour
chaque fichier de base (un seul objet donc par partition) afin d'éviter toute fragmentation du FS.
Les journaux seront hébergés par un autre groupe de disque configuré en RAID 1, la base TempDB
sera également sur ce groupe sur sa propre partition toujours pour éviter un fragmentation.
Ta réponse de 8ko me paraît tout à fait logique, mais je me demandais si opter pour une taille de
cluster plus importante (de 64ko par ex.) ne pouvait pas booster les performances.
Par ailleurs, penses tu qu'affiner la valeur max async IO peut être bénéfique en terme de
performances ?
Merci de ton intérêt.
lionelp
comme le dit Med, c'est 64Ko qui est recommandé: les lecture de data se font par extent la majeur partie du temps ==> 1 extent = 8 pages = 64Ko Pour le log ça se complique un peu car un log record peut aller de 50 octets à 64Ko (si ce n'est pas ça on en est pas très loin), donc il faut une c
-----Message d'origine----- 64ko est plus recommandé. Mais le mieux encore est de tester avec un outil comme
Le système de fichier est hébergé par un groupe de 4
disques configuré en RAID 5.
Par défaut le contrôleur opte pour des bandes de 8 ko.
Il possède un cache embarqué (32 Mo), mais
j'hésite fortement à passer en mode d'écriture différée.
Les bases de données (data) sont mono fichier, et j'ai
l'intention d'attribuer une partition pour
chaque fichier de base (un seul objet donc par partition)
afin d'éviter toute fragmentation du FS.
Les journaux seront hébergés par un autre groupe de
disque configuré en RAID 1, la base TempDB
sera également sur ce groupe sur sa propre partition
toujours pour éviter un fragmentation.
Ta réponse de 8ko me paraît tout à fait logique, mais
je me demandais si opter pour une taille de
cluster plus importante (de 64ko par ex.) ne pouvait pas
booster les performances.
Par ailleurs, penses tu qu'affiner la valeur max async
IO peut être bénéfique en terme de
performances ?
Merci de ton intérêt.
.
comme le dit Med, c'est 64Ko qui est recommandé:
les lecture de data se font par extent la majeur partie du
temps ==> 1 extent = 8 pages = 64Ko
Pour le log ça se complique un peu car un log record peut
aller de 50 octets à 64Ko (si ce n'est pas ça on en est
pas très loin), donc il faut une c
-----Message d'origine-----
64ko est plus recommandé.
Mais le mieux encore est de tester avec un outil comme
comme le dit Med, c'est 64Ko qui est recommandé: les lecture de data se font par extent la majeur partie du temps ==> 1 extent = 8 pages = 64Ko Pour le log ça se complique un peu car un log record peut aller de 50 octets à 64Ko (si ce n'est pas ça on en est pas très loin), donc il faut une c
-----Message d'origine----- 64ko est plus recommandé. Mais le mieux encore est de tester avec un outil comme
Le système de fichier est hébergé par un groupe de 4
disques configuré en RAID 5.
Par défaut le contrôleur opte pour des bandes de 8 ko.
Il possède un cache embarqué (32 Mo), mais
j'hésite fortement à passer en mode d'écriture différée.
Les bases de données (data) sont mono fichier, et j'ai
l'intention d'attribuer une partition pour
chaque fichier de base (un seul objet donc par partition)
afin d'éviter toute fragmentation du FS.
Les journaux seront hébergés par un autre groupe de
disque configuré en RAID 1, la base TempDB
sera également sur ce groupe sur sa propre partition
toujours pour éviter un fragmentation.
Ta réponse de 8ko me paraît tout à fait logique, mais
je me demandais si opter pour une taille de
cluster plus importante (de 64ko par ex.) ne pouvait pas
booster les performances.
Par ailleurs, penses tu qu'affiner la valeur max async
IO peut être bénéfique en terme de
performances ?
Merci de ton intérêt.
.
lionelp
(j'ai enlevé mes mouffles) je disais donc il faut une cache écriture qui tienne la route pour palier à la variété d'IO sur le log. Cela est à tempérer par le fait que des transactions simultanées sont bufferisées avant d'être envoyées dans le log file et là on se trouve donc avec des IO sur le log file plus proche des 64Ko. L'outil pour calibrer est l'outil mentionné par Med et perfmon (à la limite perfmon et application suffisent). concernant tempdb, on peut la mettre sur du RAID 0, RAID 1 s'il faut absolument pas de risque d'arrêt de SQL Server dû à un pb disque. tempdb est recréée à chaque redémarrage de SQL Server.
Cordialement, LionelP
-----Message d'origine----- comme le dit Med, c'est 64Ko qui est recommandé: les lecture de data se font par extent la majeur partie
du
temps ==> 1 extent = 8 pages = 64Ko Pour le log ça se complique un peu car un log record peut aller de 50 octets à 64Ko (si ce n'est pas ça on en est pas très loin), donc il faut une c
-----Message d'origine----- 64ko est plus recommandé. Mais le mieux encore est de tester avec un outil comme
Le système de fichier est hébergé par un groupe de 4
disques configuré en RAID 5.
Par défaut le contrôleur opte pour des bandes de 8 ko.
Il possède un cache embarqué (32 Mo), mais
j'hésite fortement à passer en mode d'écriture différée.
Les bases de données (data) sont mono fichier, et j'ai
l'intention d'attribuer une partition pour
chaque fichier de base (un seul objet donc par
partition)
afin d'éviter toute fragmentation du FS.
Les journaux seront hébergés par un autre groupe de
disque configuré en RAID 1, la base TempDB
sera également sur ce groupe sur sa propre partition
toujours pour éviter un fragmentation.
Ta réponse de 8ko me paraît tout à fait logique, mais
je me demandais si opter pour une taille de
cluster plus importante (de 64ko par ex.) ne pouvait pas
booster les performances.
Par ailleurs, penses tu qu'affiner la valeur max async
IO peut être bénéfique en terme de
performances ?
Merci de ton intérêt.
.
.
(j'ai enlevé mes mouffles) je disais donc il faut une
cache écriture qui tienne la route pour palier à la
variété d'IO sur le log. Cela est à tempérer par le fait
que des transactions simultanées sont bufferisées avant
d'être envoyées dans le log file et là on se trouve donc
avec des IO sur le log file plus proche des 64Ko. L'outil
pour calibrer est l'outil mentionné par Med et perfmon (à
la limite perfmon et application suffisent).
concernant tempdb, on peut la mettre sur du RAID 0, RAID 1
s'il faut absolument pas de risque d'arrêt de SQL Server
dû à un pb disque. tempdb est recréée à chaque redémarrage
de SQL Server.
Cordialement,
LionelP
-----Message d'origine-----
comme le dit Med, c'est 64Ko qui est recommandé:
les lecture de data se font par extent la majeur partie
du
temps ==> 1 extent = 8 pages = 64Ko
Pour le log ça se complique un peu car un log record peut
aller de 50 octets à 64Ko (si ce n'est pas ça on en est
pas très loin), donc il faut une c
-----Message d'origine-----
64ko est plus recommandé.
Mais le mieux encore est de tester avec un outil comme
(j'ai enlevé mes mouffles) je disais donc il faut une cache écriture qui tienne la route pour palier à la variété d'IO sur le log. Cela est à tempérer par le fait que des transactions simultanées sont bufferisées avant d'être envoyées dans le log file et là on se trouve donc avec des IO sur le log file plus proche des 64Ko. L'outil pour calibrer est l'outil mentionné par Med et perfmon (à la limite perfmon et application suffisent). concernant tempdb, on peut la mettre sur du RAID 0, RAID 1 s'il faut absolument pas de risque d'arrêt de SQL Server dû à un pb disque. tempdb est recréée à chaque redémarrage de SQL Server.
Cordialement, LionelP
-----Message d'origine----- comme le dit Med, c'est 64Ko qui est recommandé: les lecture de data se font par extent la majeur partie
du
temps ==> 1 extent = 8 pages = 64Ko Pour le log ça se complique un peu car un log record peut aller de 50 octets à 64Ko (si ce n'est pas ça on en est pas très loin), donc il faut une c
-----Message d'origine----- 64ko est plus recommandé. Mais le mieux encore est de tester avec un outil comme
