bonjour ,
j'ai posté une question a propos du partitionnement de base de donnée s SQL
2005 sur un NAS et j'ai eu des retours tres precis (merci)
seulement il y avait confusion le serveur etait bien rattaché a un SAN et
non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
Auriez vous des consignes particuliers a respecter pour partitionner des
grosses tables sur plusieurs groupes de fichier sur un san?
Faut il créer des volumes specifiques , y a t'il des options a activer ?
sachant que nous n'avons pas d'experience particulier sur les san
Merci d'avance pour toute aide
hch
bonjour ,
j'ai posté une question a propos du partitionnement de base de donnée s SQL
2005 sur un NAS et j'ai eu des retours tres precis (merci)
seulement il y avait confusion le serveur etait bien rattaché a un SAN et
non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
Auriez vous des consignes particuliers a respecter pour partitionner des
grosses tables sur plusieurs groupes de fichier sur un san?
Faut il créer des volumes specifiques , y a t'il des options a activer ?
sachant que nous n'avons pas d'experience particulier sur les san
Merci d'avance pour toute aide
hch
bonjour ,
j'ai posté une question a propos du partitionnement de base de donnée s SQL
2005 sur un NAS et j'ai eu des retours tres precis (merci)
seulement il y avait confusion le serveur etait bien rattaché a un SAN et
non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
Auriez vous des consignes particuliers a respecter pour partitionner des
grosses tables sur plusieurs groupes de fichier sur un san?
Faut il créer des volumes specifiques , y a t'il des options a activer ?
sachant que nous n'avons pas d'experience particulier sur les san
Merci d'avance pour toute aide
hch
Bonjour,
oui il faut créer des volumes spécifiques, physiquement distinct sur
le SAN pour chaque groupe de fichier. Il est aussi possible de
partitionner les index, cela peut dans certaines conditions améliorer
les performance. Cela s'applique aux très grandes tables et demande à
être étudié au préalable soigneusement, voici deux liens vers des doc
techniques, il en existe beaucoup d'autres :
http://msdn.microsoft.com/en-us/library/ms345146.aspx
http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx
Une première optimisation, plus simple à mettre en œuvre est de
séparer les fichiers des données et les fichiers des journaux sur des
unités physiquement distinctes.
Chaque volume physique du SAN doit être en RAID 1 ou 10 pour les
journaux, RAID 1, 5 ou 10 pour les data.
La recherche de performances n'est pas liée uniquement au stockage, il
y a de nombreux axes à explorer, conception du modèle, index,
fragmentation...
Phil
On 18 juin, 22:15, hch wrote:
> bonjour ,
>
> j'ai posté une question a propos du partitionnement de base de données SQL
> 2005 sur un NAS et j'ai eu des retours tres precis (merci)
> seulement il y avait confusion le serveur etait bien rattaché a un SAN et
> non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
>
> Auriez vous des consignes particuliers a respecter pour partitionner des
> grosses tables sur plusieurs groupes de fichier sur un san?
>
> Faut il créer des volumes specifiques , y a t'il des options a activer ?
> sachant que nous n'avons pas d'experience particulier sur les san
>
> Merci d'avance pour toute aide
> hch
Bonjour,
oui il faut créer des volumes spécifiques, physiquement distinct sur
le SAN pour chaque groupe de fichier. Il est aussi possible de
partitionner les index, cela peut dans certaines conditions améliorer
les performance. Cela s'applique aux très grandes tables et demande à
être étudié au préalable soigneusement, voici deux liens vers des doc
techniques, il en existe beaucoup d'autres :
http://msdn.microsoft.com/en-us/library/ms345146.aspx
http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx
Une première optimisation, plus simple à mettre en œuvre est de
séparer les fichiers des données et les fichiers des journaux sur des
unités physiquement distinctes.
Chaque volume physique du SAN doit être en RAID 1 ou 10 pour les
journaux, RAID 1, 5 ou 10 pour les data.
La recherche de performances n'est pas liée uniquement au stockage, il
y a de nombreux axes à explorer, conception du modèle, index,
fragmentation...
Phil
On 18 juin, 22:15, hch <h...@discussions.microsoft.com> wrote:
> bonjour ,
>
> j'ai posté une question a propos du partitionnement de base de données SQL
> 2005 sur un NAS et j'ai eu des retours tres precis (merci)
> seulement il y avait confusion le serveur etait bien rattaché a un SAN et
> non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
>
> Auriez vous des consignes particuliers a respecter pour partitionner des
> grosses tables sur plusieurs groupes de fichier sur un san?
>
> Faut il créer des volumes specifiques , y a t'il des options a activer ?
> sachant que nous n'avons pas d'experience particulier sur les san
>
> Merci d'avance pour toute aide
> hch
Bonjour,
oui il faut créer des volumes spécifiques, physiquement distinct sur
le SAN pour chaque groupe de fichier. Il est aussi possible de
partitionner les index, cela peut dans certaines conditions améliorer
les performance. Cela s'applique aux très grandes tables et demande à
être étudié au préalable soigneusement, voici deux liens vers des doc
techniques, il en existe beaucoup d'autres :
http://msdn.microsoft.com/en-us/library/ms345146.aspx
http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx
Une première optimisation, plus simple à mettre en œuvre est de
séparer les fichiers des données et les fichiers des journaux sur des
unités physiquement distinctes.
Chaque volume physique du SAN doit être en RAID 1 ou 10 pour les
journaux, RAID 1, 5 ou 10 pour les data.
La recherche de performances n'est pas liée uniquement au stockage, il
y a de nombreux axes à explorer, conception du modèle, index,
fragmentation...
Phil
On 18 juin, 22:15, hch wrote:
> bonjour ,
>
> j'ai posté une question a propos du partitionnement de base de données SQL
> 2005 sur un NAS et j'ai eu des retours tres precis (merci)
> seulement il y avait confusion le serveur etait bien rattaché a un SAN et
> non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
>
> Auriez vous des consignes particuliers a respecter pour partitionner des
> grosses tables sur plusieurs groupes de fichier sur un san?
>
> Faut il créer des volumes specifiques , y a t'il des options a activer ?
> sachant que nous n'avons pas d'experience particulier sur les san
>
> Merci d'avance pour toute aide
> hch
merci,
les optimisations de modele et de requetes sont faites deja ,il nous reste
le partiotionnement et l'alignement des indexes
nous allons essayer de créer des volumes physiques pour chaque Groupe de
fichiers
hch
"Phil" wrote:Bonjour,
oui il faut créer des volumes spécifiques, physiquement distinct sur
le SAN pour chaque groupe de fichier. Il est aussi possible de
partitionner les index, cela peut dans certaines conditions améliorer
les performance. Cela s'applique aux très grandes tables et demande à
être étudié au préalable soigneusement, voici deux liens vers des doc
techniques, il en existe beaucoup d'autres :
http://msdn.microsoft.com/en-us/library/ms345146.aspx
http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx
Une première optimisation, plus simple à mettre en œuvre est de
séparer les fichiers des données et les fichiers des journaux sur des
unités physiquement distinctes.
Chaque volume physique du SAN doit être en RAID 1 ou 10 pour les
journaux, RAID 1, 5 ou 10 pour les data.
La recherche de performances n'est pas liée uniquement au stockage, il
y a de nombreux axes à explorer, conception du modèle, index,
fragmentation...
Phil
On 18 juin, 22:15, hch wrote:bonjour ,
j'ai posté une question a propos du partitionnement de base de données SQL
2005 sur un NAS et j'ai eu des retours tres precis (merci)
seulement il y avait confusion le serveur etait bien rattaché a un SAN et
non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
Auriez vous des consignes particuliers a respecter pour partitionner des
grosses tables sur plusieurs groupes de fichier sur un san?
Faut il créer des volumes specifiques , y a t'il des options a activer ?
sachant que nous n'avons pas d'experience particulier sur les san
Merci d'avance pour toute aide
hch
merci,
les optimisations de modele et de requetes sont faites deja ,il nous reste
le partiotionnement et l'alignement des indexes
nous allons essayer de créer des volumes physiques pour chaque Groupe de
fichiers
hch
"Phil" wrote:
Bonjour,
oui il faut créer des volumes spécifiques, physiquement distinct sur
le SAN pour chaque groupe de fichier. Il est aussi possible de
partitionner les index, cela peut dans certaines conditions améliorer
les performance. Cela s'applique aux très grandes tables et demande à
être étudié au préalable soigneusement, voici deux liens vers des doc
techniques, il en existe beaucoup d'autres :
http://msdn.microsoft.com/en-us/library/ms345146.aspx
http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx
Une première optimisation, plus simple à mettre en œuvre est de
séparer les fichiers des données et les fichiers des journaux sur des
unités physiquement distinctes.
Chaque volume physique du SAN doit être en RAID 1 ou 10 pour les
journaux, RAID 1, 5 ou 10 pour les data.
La recherche de performances n'est pas liée uniquement au stockage, il
y a de nombreux axes à explorer, conception du modèle, index,
fragmentation...
Phil
On 18 juin, 22:15, hch <h...@discussions.microsoft.com> wrote:
bonjour ,
j'ai posté une question a propos du partitionnement de base de données SQL
2005 sur un NAS et j'ai eu des retours tres precis (merci)
seulement il y avait confusion le serveur etait bien rattaché a un SAN et
non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
Auriez vous des consignes particuliers a respecter pour partitionner des
grosses tables sur plusieurs groupes de fichier sur un san?
Faut il créer des volumes specifiques , y a t'il des options a activer ?
sachant que nous n'avons pas d'experience particulier sur les san
Merci d'avance pour toute aide
hch
merci,
les optimisations de modele et de requetes sont faites deja ,il nous reste
le partiotionnement et l'alignement des indexes
nous allons essayer de créer des volumes physiques pour chaque Groupe de
fichiers
hch
"Phil" wrote:Bonjour,
oui il faut créer des volumes spécifiques, physiquement distinct sur
le SAN pour chaque groupe de fichier. Il est aussi possible de
partitionner les index, cela peut dans certaines conditions améliorer
les performance. Cela s'applique aux très grandes tables et demande à
être étudié au préalable soigneusement, voici deux liens vers des doc
techniques, il en existe beaucoup d'autres :
http://msdn.microsoft.com/en-us/library/ms345146.aspx
http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx
Une première optimisation, plus simple à mettre en œuvre est de
séparer les fichiers des données et les fichiers des journaux sur des
unités physiquement distinctes.
Chaque volume physique du SAN doit être en RAID 1 ou 10 pour les
journaux, RAID 1, 5 ou 10 pour les data.
La recherche de performances n'est pas liée uniquement au stockage, il
y a de nombreux axes à explorer, conception du modèle, index,
fragmentation...
Phil
On 18 juin, 22:15, hch wrote:bonjour ,
j'ai posté une question a propos du partitionnement de base de données SQL
2005 sur un NAS et j'ai eu des retours tres precis (merci)
seulement il y avait confusion le serveur etait bien rattaché a un SAN et
non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
Auriez vous des consignes particuliers a respecter pour partitionner des
grosses tables sur plusieurs groupes de fichier sur un san?
Faut il créer des volumes specifiques , y a t'il des options a activer ?
sachant que nous n'avons pas d'experience particulier sur les san
Merci d'avance pour toute aide
hch
Il faut en fait aligner vos LUN sur des agrégats physiques.
Il est aussi fortement conseillé que le SAN soit dédié et non partagé !
En fonction du nombre de disques et des agrégats possible, voici quelques
exemples :
32 bits :
5 disques :
0 - RAID 1 : os, exe, pagefile.sys, JT
1 - RAID 5 : data
7 disques :
0 - RAID 1 : os, exe, pagefile.sys
1 - RAID 5 : data
2 - RAID 1 : JT
9 disques :
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : pagefile.sys
12 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : pagefile.sys
4 - RAID 1 : index
16 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data1
2 - RAID 5 : data2
3 - RAID 10 : JT
4 - RAID 1 : pagefile.sys
5 - RAID 1 : index
64 bits :
5 disques :
0 - RAID 1 : os, exe, JT
1 - RAID 5 : data
7 disques :
0 - RAID 1 : os, exe
1 - RAID 5 : data
2 - RAID 1 : JT
9 disques :
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : index
12 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : index
4 - RAID 1 : tempdb
16 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data1
2 - RAID 5 : data2
3 - RAID 10 : JT
4 - RAID 1 : tempdb
5 - RAID 1 : index
ETC...
A +
hch a écrit :merci, les optimisations de modele et de requetes sont faites deja ,il
nous reste le partiotionnement et l'alignement des indexes nous allons
essayer de créer des volumes physiques pour chaque Groupe de fichiers hch
"Phil" wrote:Bonjour,
oui il faut créer des volumes spécifiques, physiquement distinct sur
le SAN pour chaque groupe de fichier. Il est aussi possible de
partitionner les index, cela peut dans certaines conditions améliorer
les performance. Cela s'applique aux très grandes tables et demande à
être étudié au préalable soigneusement, voici deux liens vers des doc
techniques, il en existe beaucoup d'autres :
http://msdn.microsoft.com/en-us/library/ms345146.aspx
http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx
Une première optimisation, plus simple à mettre en œuvre est de
séparer les fichiers des données et les fichiers des journaux sur des
unités physiquement distinctes.
Chaque volume physique du SAN doit être en RAID 1 ou 10 pour les
journaux, RAID 1, 5 ou 10 pour les data.
La recherche de performances n'est pas liée uniquement au stockage, il
y a de nombreux axes à explorer, conception du modèle, index,
fragmentation...
Phil
On 18 juin, 22:15, hch wrote:bonjour ,
j'ai posté une question a propos du partitionnement de base de données
SQL
2005 sur un NAS et j'ai eu des retours tres precis (merci)
seulement il y avait confusion le serveur etait bien rattaché a un SAN
et
non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
Auriez vous des consignes particuliers a respecter pour partitionner
des
grosses tables sur plusieurs groupes de fichier sur un san?
Faut il créer des volumes specifiques , y a t'il des options a activer
?
sachant que nous n'avons pas d'experience particulier sur les san
Merci d'avance pour toute aide
hch
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Il faut en fait aligner vos LUN sur des agrégats physiques.
Il est aussi fortement conseillé que le SAN soit dédié et non partagé !
En fonction du nombre de disques et des agrégats possible, voici quelques
exemples :
32 bits :
5 disques :
0 - RAID 1 : os, exe, pagefile.sys, JT
1 - RAID 5 : data
7 disques :
0 - RAID 1 : os, exe, pagefile.sys
1 - RAID 5 : data
2 - RAID 1 : JT
9 disques :
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : pagefile.sys
12 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : pagefile.sys
4 - RAID 1 : index
16 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data1
2 - RAID 5 : data2
3 - RAID 10 : JT
4 - RAID 1 : pagefile.sys
5 - RAID 1 : index
64 bits :
5 disques :
0 - RAID 1 : os, exe, JT
1 - RAID 5 : data
7 disques :
0 - RAID 1 : os, exe
1 - RAID 5 : data
2 - RAID 1 : JT
9 disques :
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : index
12 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : index
4 - RAID 1 : tempdb
16 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data1
2 - RAID 5 : data2
3 - RAID 10 : JT
4 - RAID 1 : tempdb
5 - RAID 1 : index
ETC...
A +
hch a écrit :
merci, les optimisations de modele et de requetes sont faites deja ,il
nous reste le partiotionnement et l'alignement des indexes nous allons
essayer de créer des volumes physiques pour chaque Groupe de fichiers hch
"Phil" wrote:
Bonjour,
oui il faut créer des volumes spécifiques, physiquement distinct sur
le SAN pour chaque groupe de fichier. Il est aussi possible de
partitionner les index, cela peut dans certaines conditions améliorer
les performance. Cela s'applique aux très grandes tables et demande à
être étudié au préalable soigneusement, voici deux liens vers des doc
techniques, il en existe beaucoup d'autres :
http://msdn.microsoft.com/en-us/library/ms345146.aspx
http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx
Une première optimisation, plus simple à mettre en œuvre est de
séparer les fichiers des données et les fichiers des journaux sur des
unités physiquement distinctes.
Chaque volume physique du SAN doit être en RAID 1 ou 10 pour les
journaux, RAID 1, 5 ou 10 pour les data.
La recherche de performances n'est pas liée uniquement au stockage, il
y a de nombreux axes à explorer, conception du modèle, index,
fragmentation...
Phil
On 18 juin, 22:15, hch <h...@discussions.microsoft.com> wrote:
bonjour ,
j'ai posté une question a propos du partitionnement de base de données
SQL
2005 sur un NAS et j'ai eu des retours tres precis (merci)
seulement il y avait confusion le serveur etait bien rattaché a un SAN
et
non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
Auriez vous des consignes particuliers a respecter pour partitionner
des
grosses tables sur plusieurs groupes de fichier sur un san?
Faut il créer des volumes specifiques , y a t'il des options a activer
?
sachant que nous n'avons pas d'experience particulier sur les san
Merci d'avance pour toute aide
hch
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Il faut en fait aligner vos LUN sur des agrégats physiques.
Il est aussi fortement conseillé que le SAN soit dédié et non partagé !
En fonction du nombre de disques et des agrégats possible, voici quelques
exemples :
32 bits :
5 disques :
0 - RAID 1 : os, exe, pagefile.sys, JT
1 - RAID 5 : data
7 disques :
0 - RAID 1 : os, exe, pagefile.sys
1 - RAID 5 : data
2 - RAID 1 : JT
9 disques :
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : pagefile.sys
12 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : pagefile.sys
4 - RAID 1 : index
16 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data1
2 - RAID 5 : data2
3 - RAID 10 : JT
4 - RAID 1 : pagefile.sys
5 - RAID 1 : index
64 bits :
5 disques :
0 - RAID 1 : os, exe, JT
1 - RAID 5 : data
7 disques :
0 - RAID 1 : os, exe
1 - RAID 5 : data
2 - RAID 1 : JT
9 disques :
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : index
12 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data
2 - RAID 1 : JT
3 - RAID 1 : index
4 - RAID 1 : tempdb
16 disques
0 - RAID 1 : os, exe,
1 - RAID 5 : data1
2 - RAID 5 : data2
3 - RAID 10 : JT
4 - RAID 1 : tempdb
5 - RAID 1 : index
ETC...
A +
hch a écrit :merci, les optimisations de modele et de requetes sont faites deja ,il
nous reste le partiotionnement et l'alignement des indexes nous allons
essayer de créer des volumes physiques pour chaque Groupe de fichiers hch
"Phil" wrote:Bonjour,
oui il faut créer des volumes spécifiques, physiquement distinct sur
le SAN pour chaque groupe de fichier. Il est aussi possible de
partitionner les index, cela peut dans certaines conditions améliorer
les performance. Cela s'applique aux très grandes tables et demande à
être étudié au préalable soigneusement, voici deux liens vers des doc
techniques, il en existe beaucoup d'autres :
http://msdn.microsoft.com/en-us/library/ms345146.aspx
http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx
Une première optimisation, plus simple à mettre en œuvre est de
séparer les fichiers des données et les fichiers des journaux sur des
unités physiquement distinctes.
Chaque volume physique du SAN doit être en RAID 1 ou 10 pour les
journaux, RAID 1, 5 ou 10 pour les data.
La recherche de performances n'est pas liée uniquement au stockage, il
y a de nombreux axes à explorer, conception du modèle, index,
fragmentation...
Phil
On 18 juin, 22:15, hch wrote:bonjour ,
j'ai posté une question a propos du partitionnement de base de données
SQL
2005 sur un NAS et j'ai eu des retours tres precis (merci)
seulement il y avait confusion le serveur etait bien rattaché a un SAN
et
non un NAS et malgres ceci nous n'avons pas eu de meilleures perf
Auriez vous des consignes particuliers a respecter pour partitionner
des
grosses tables sur plusieurs groupes de fichier sur un san?
Faut il créer des volumes specifiques , y a t'il des options a activer
?
sachant que nous n'avons pas d'experience particulier sur les san
Merci d'avance pour toute aide
hch
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************