Bonjour / Bonsoir,
Une question technique concernant les disques
Dans ma boite, nous allons faire évoluer un serveur SQL 2000, actuellement
avec des disques en RAID5 (6x32Go) uniquement
Il contient une base de 60Go environ, non journalisée, et quelques autres
bases journalisées mais de 100/200Mo maxi.
Par moment, lorsque certains utilisateurs font de méga requetes d'insert
la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture aussi
bien qu'en écriture. Idem lors de la création d'index clustered par
Est-ce que si les journaux de transactions et la tempdb étaient sur
disques, par exemple en miroir, ça améliorerait les choses. Ou est-ce que
c'est la carte RAID qui pourrait être trop lente (pas assez de mémoire
cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
Merci d'avance
Sébastien
Bonjour / Bonsoir,
Une question technique concernant les disques
Dans ma boite, nous allons faire évoluer un serveur SQL 2000, actuellement
avec des disques en RAID5 (6x32Go) uniquement
Il contient une base de 60Go environ, non journalisée, et quelques autres
bases journalisées mais de 100/200Mo maxi.
Par moment, lorsque certains utilisateurs font de méga requetes d'insert
la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture aussi
bien qu'en écriture. Idem lors de la création d'index clustered par
Est-ce que si les journaux de transactions et la tempdb étaient sur
disques, par exemple en miroir, ça améliorerait les choses. Ou est-ce que
c'est la carte RAID qui pourrait être trop lente (pas assez de mémoire
cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
Merci d'avance
Sébastien
Bonjour / Bonsoir,
Une question technique concernant les disques
Dans ma boite, nous allons faire évoluer un serveur SQL 2000, actuellement
avec des disques en RAID5 (6x32Go) uniquement
Il contient une base de 60Go environ, non journalisée, et quelques autres
bases journalisées mais de 100/200Mo maxi.
Par moment, lorsque certains utilisateurs font de méga requetes d'insert
la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture aussi
bien qu'en écriture. Idem lors de la création d'index clustered par
Est-ce que si les journaux de transactions et la tempdb étaient sur
disques, par exemple en miroir, ça améliorerait les choses. Ou est-ce que
c'est la carte RAID qui pourrait être trop lente (pas assez de mémoire
cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
Merci d'avance
Sébastien
Puisque tu évolues vers une nouvelle machine, il faut prévoir idéalement :
1) Un RAID 1 pour l' OS
2) Un autre RAID 1 pour les log
Les IO sur le log sont essentiellement séquentiels.
S'il n'y a qu'un seul fichier de log, il serait intéressant de le
placer sur un RAID 1
L'avantage s'estompe quelque peu s'il y a plusieurs fichiers log.
Quoi qu'il en soit, il est toujours intéressant de mettre le log à
part.
3) Un RAID 0 pour TempDB
Inutile de prévoir de la tolérance de panne pour TempDB.
Elle peut se contenter d'un RAID 0 car elle est reconstruite à chaque
démarrage de SQL Server
4) Un RAID 5 pour les data
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Sebastien" wrote in message
news:O#3w64x#
> Bonjour / Bonsoir,
>
> Une question technique concernant les disques
>
> Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> avec des disques en RAID5 (6x32Go) uniquement
> Il contient une base de 60Go environ, non journalisée, et quelques
> bases journalisées mais de 100/200Mo maxi.
> Par moment, lorsque certains utilisateurs font de méga requetes d'insert
sur
> la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture aussi
> bien qu'en écriture. Idem lors de la création d'index clustered par
exemple.
> Est-ce que si les journaux de transactions et la tempdb étaient sur
d'autres
> disques, par exemple en miroir, ça améliorerait les choses. Ou est-ce
> c'est la carte RAID qui pourrait être trop lente (pas assez de mémoire
> cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
>
> Merci d'avance
> Sébastien
>
Puisque tu évolues vers une nouvelle machine, il faut prévoir idéalement :
1) Un RAID 1 pour l' OS
2) Un autre RAID 1 pour les log
Les IO sur le log sont essentiellement séquentiels.
S'il n'y a qu'un seul fichier de log, il serait intéressant de le
placer sur un RAID 1
L'avantage s'estompe quelque peu s'il y a plusieurs fichiers log.
Quoi qu'il en soit, il est toujours intéressant de mettre le log à
part.
3) Un RAID 0 pour TempDB
Inutile de prévoir de la tolérance de panne pour TempDB.
Elle peut se contenter d'un RAID 0 car elle est reconstruite à chaque
démarrage de SQL Server
4) Un RAID 5 pour les data
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Sebastien" <sebastien.dubosc.no.sp.am@m6net.fr> wrote in message
news:O#3w64x#DHA.3184@TK2MSFTNGP09.phx.gbl...
> Bonjour / Bonsoir,
>
> Une question technique concernant les disques
>
> Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> avec des disques en RAID5 (6x32Go) uniquement
> Il contient une base de 60Go environ, non journalisée, et quelques
> bases journalisées mais de 100/200Mo maxi.
> Par moment, lorsque certains utilisateurs font de méga requetes d'insert
sur
> la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture aussi
> bien qu'en écriture. Idem lors de la création d'index clustered par
exemple.
> Est-ce que si les journaux de transactions et la tempdb étaient sur
d'autres
> disques, par exemple en miroir, ça améliorerait les choses. Ou est-ce
> c'est la carte RAID qui pourrait être trop lente (pas assez de mémoire
> cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
>
> Merci d'avance
> Sébastien
>
Puisque tu évolues vers une nouvelle machine, il faut prévoir idéalement :
1) Un RAID 1 pour l' OS
2) Un autre RAID 1 pour les log
Les IO sur le log sont essentiellement séquentiels.
S'il n'y a qu'un seul fichier de log, il serait intéressant de le
placer sur un RAID 1
L'avantage s'estompe quelque peu s'il y a plusieurs fichiers log.
Quoi qu'il en soit, il est toujours intéressant de mettre le log à
part.
3) Un RAID 0 pour TempDB
Inutile de prévoir de la tolérance de panne pour TempDB.
Elle peut se contenter d'un RAID 0 car elle est reconstruite à chaque
démarrage de SQL Server
4) Un RAID 5 pour les data
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Sebastien" wrote in message
news:O#3w64x#
> Bonjour / Bonsoir,
>
> Une question technique concernant les disques
>
> Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> avec des disques en RAID5 (6x32Go) uniquement
> Il contient une base de 60Go environ, non journalisée, et quelques
> bases journalisées mais de 100/200Mo maxi.
> Par moment, lorsque certains utilisateurs font de méga requetes d'insert
sur
> la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture aussi
> bien qu'en écriture. Idem lors de la création d'index clustered par
exemple.
> Est-ce que si les journaux de transactions et la tempdb étaient sur
d'autres
> disques, par exemple en miroir, ça améliorerait les choses. Ou est-ce
> c'est la carte RAID qui pourrait être trop lente (pas assez de mémoire
> cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
>
> Merci d'avance
> Sébastien
>
> Les logs me semblent plus importantes que les data.
Les logs me semblent plus importantes que les data.
En cas de crash sur le disque data, les data non sauvegardées sont
entièrement récupérables par full restore + logs, alors que rien ne permet
de récupérer des logs non sauvegardés.
Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
Jacques.
"Med Bouchenafa[MVP]" a écrit dans le message de
news: #JkQV23#
> Puisque tu évolues vers une nouvelle machine, il faut prévoir idéalement
>
> 1) Un RAID 1 pour l' OS
>
> 2) Un autre RAID 1 pour les log
> Les IO sur le log sont essentiellement séquentiels.
> S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> placer sur un RAID 1
> L'avantage s'estompe quelque peu s'il y a plusieurs fichiers log.
> Quoi qu'il en soit, il est toujours intéressant de mettre le log à
> part.
>
> 3) Un RAID 0 pour TempDB
> Inutile de prévoir de la tolérance de panne pour TempDB.
> Elle peut se contenter d'un RAID 0 car elle est reconstruite à
> démarrage de SQL Server
>
> 4) Un RAID 5 pour les data
>
>
> --
> Bien cordialement
> Med Bouchenafa
> TETRASET
> 75015 Paris
> "Sebastien" wrote in message
> news:O#3w64x#
> > Bonjour / Bonsoir,
> >
> > Une question technique concernant les disques
> >
> > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
actuellement
> > avec des disques en RAID5 (6x32Go) uniquement
> > Il contient une base de 60Go environ, non journalisée, et quelques
autres
> > bases journalisées mais de 100/200Mo maxi.
> > Par moment, lorsque certains utilisateurs font de méga requetes
> sur
> > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
> > bien qu'en écriture. Idem lors de la création d'index clustered par
> exemple.
> > Est-ce que si les journaux de transactions et la tempdb étaient sur
> d'autres
> > disques, par exemple en miroir, ça améliorerait les choses. Ou est-ce
que
> > c'est la carte RAID qui pourrait être trop lente (pas assez de mémoire
> > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> >
> > Merci d'avance
> > Sébastien
> >
>
>
> Les logs me semblent plus importantes que les data.
Les logs me semblent plus importantes que les data.
En cas de crash sur le disque data, les data non sauvegardées sont
entièrement récupérables par full restore + logs, alors que rien ne permet
de récupérer des logs non sauvegardés.
Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
Jacques.
"Med Bouchenafa[MVP]" <com.tetraset@bouchenafa> a écrit dans le message de
news: #JkQV23#DHA.2212@TK2MSFTNGP10.phx.gbl...
> Puisque tu évolues vers une nouvelle machine, il faut prévoir idéalement
>
> 1) Un RAID 1 pour l' OS
>
> 2) Un autre RAID 1 pour les log
> Les IO sur le log sont essentiellement séquentiels.
> S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> placer sur un RAID 1
> L'avantage s'estompe quelque peu s'il y a plusieurs fichiers log.
> Quoi qu'il en soit, il est toujours intéressant de mettre le log à
> part.
>
> 3) Un RAID 0 pour TempDB
> Inutile de prévoir de la tolérance de panne pour TempDB.
> Elle peut se contenter d'un RAID 0 car elle est reconstruite à
> démarrage de SQL Server
>
> 4) Un RAID 5 pour les data
>
>
> --
> Bien cordialement
> Med Bouchenafa
> TETRASET
> 75015 Paris
> "Sebastien" <sebastien.dubosc.no.sp.am@m6net.fr> wrote in message
> news:O#3w64x#DHA.3184@TK2MSFTNGP09.phx.gbl...
> > Bonjour / Bonsoir,
> >
> > Une question technique concernant les disques
> >
> > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
actuellement
> > avec des disques en RAID5 (6x32Go) uniquement
> > Il contient une base de 60Go environ, non journalisée, et quelques
autres
> > bases journalisées mais de 100/200Mo maxi.
> > Par moment, lorsque certains utilisateurs font de méga requetes
> sur
> > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
> > bien qu'en écriture. Idem lors de la création d'index clustered par
> exemple.
> > Est-ce que si les journaux de transactions et la tempdb étaient sur
> d'autres
> > disques, par exemple en miroir, ça améliorerait les choses. Ou est-ce
que
> > c'est la carte RAID qui pourrait être trop lente (pas assez de mémoire
> > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> >
> > Merci d'avance
> > Sébastien
> >
>
>
> Les logs me semblent plus importantes que les data.
Les logs me semblent plus importantes que les data.
En cas de crash sur le disque data, les data non sauvegardées sont
entièrement récupérables par full restore + logs, alors que rien ne permet
de récupérer des logs non sauvegardés.
Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
Jacques.
"Med Bouchenafa[MVP]" a écrit dans le message de
news: #JkQV23#
> Puisque tu évolues vers une nouvelle machine, il faut prévoir idéalement
>
> 1) Un RAID 1 pour l' OS
>
> 2) Un autre RAID 1 pour les log
> Les IO sur le log sont essentiellement séquentiels.
> S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> placer sur un RAID 1
> L'avantage s'estompe quelque peu s'il y a plusieurs fichiers log.
> Quoi qu'il en soit, il est toujours intéressant de mettre le log à
> part.
>
> 3) Un RAID 0 pour TempDB
> Inutile de prévoir de la tolérance de panne pour TempDB.
> Elle peut se contenter d'un RAID 0 car elle est reconstruite à
> démarrage de SQL Server
>
> 4) Un RAID 5 pour les data
>
>
> --
> Bien cordialement
> Med Bouchenafa
> TETRASET
> 75015 Paris
> "Sebastien" wrote in message
> news:O#3w64x#
> > Bonjour / Bonsoir,
> >
> > Une question technique concernant les disques
> >
> > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
actuellement
> > avec des disques en RAID5 (6x32Go) uniquement
> > Il contient une base de 60Go environ, non journalisée, et quelques
autres
> > bases journalisées mais de 100/200Mo maxi.
> > Par moment, lorsque certains utilisateurs font de méga requetes
> sur
> > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
> > bien qu'en écriture. Idem lors de la création d'index clustered par
> exemple.
> > Est-ce que si les journaux de transactions et la tempdb étaient sur
> d'autres
> > disques, par exemple en miroir, ça améliorerait les choses. Ou est-ce
que
> > c'est la carte RAID qui pourrait être trop lente (pas assez de mémoire
> > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> >
> > Merci d'avance
> > Sébastien
> >
>
>
> Les logs me semblent plus importantes que les data.
Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
prendre en compte.
Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
lecture
Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
moteur
Pour les données, c'est plutôt la lecture que l'on doit privilégier
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Vuillermet Jacques" wrote in message
news:Oamk9R4#
> Les logs me semblent plus importantes que les data.
> En cas de crash sur le disque data, les data non sauvegardées sont
> entièrement récupérables par full restore + logs, alors que rien ne
> de récupérer des logs non sauvegardés.
>
> Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
>
> Jacques.
>
>
> "Med Bouchenafa[MVP]" a écrit dans le message
> news: #JkQV23#
> > Puisque tu évolues vers une nouvelle machine, il faut prévoir
:
> >
> > 1) Un RAID 1 pour l' OS
> >
> > 2) Un autre RAID 1 pour les log
> > Les IO sur le log sont essentiellement séquentiels.
> > S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> > placer sur un RAID 1
> > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
> > Quoi qu'il en soit, il est toujours intéressant de mettre le log
> > part.
> >
> > 3) Un RAID 0 pour TempDB
> > Inutile de prévoir de la tolérance de panne pour TempDB.
> > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
chaque
> > démarrage de SQL Server
> >
> > 4) Un RAID 5 pour les data
> >
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> > TETRASET
> > 75015 Paris
> > "Sebastien" wrote in message
> > news:O#3w64x#
> > > Bonjour / Bonsoir,
> > >
> > > Une question technique concernant les disques
> > >
> > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> actuellement
> > > avec des disques en RAID5 (6x32Go) uniquement
> > > Il contient une base de 60Go environ, non journalisée, et quelques
> autres
> > > bases journalisées mais de 100/200Mo maxi.
> > > Par moment, lorsque certains utilisateurs font de méga requetes
d'insert
> > sur
> > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
aussi
> > > bien qu'en écriture. Idem lors de la création d'index clustered par
> > exemple.
> > > Est-ce que si les journaux de transactions et la tempdb étaient sur
> > d'autres
> > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> que
> > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > >
> > > Merci d'avance
> > > Sébastien
> > >
> >
> >
>
>
> Les logs me semblent plus importantes que les data.
Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
prendre en compte.
Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
lecture
Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
moteur
Pour les données, c'est plutôt la lecture que l'on doit privilégier
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Vuillermet Jacques" <jvuillermet@no-spam.fr> wrote in message
news:Oamk9R4#DHA.792@TK2MSFTNGP11.phx.gbl...
> Les logs me semblent plus importantes que les data.
> En cas de crash sur le disque data, les data non sauvegardées sont
> entièrement récupérables par full restore + logs, alors que rien ne
> de récupérer des logs non sauvegardés.
>
> Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
>
> Jacques.
>
>
> "Med Bouchenafa[MVP]" <com.tetraset@bouchenafa> a écrit dans le message
> news: #JkQV23#DHA.2212@TK2MSFTNGP10.phx.gbl...
> > Puisque tu évolues vers une nouvelle machine, il faut prévoir
:
> >
> > 1) Un RAID 1 pour l' OS
> >
> > 2) Un autre RAID 1 pour les log
> > Les IO sur le log sont essentiellement séquentiels.
> > S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> > placer sur un RAID 1
> > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
> > Quoi qu'il en soit, il est toujours intéressant de mettre le log
> > part.
> >
> > 3) Un RAID 0 pour TempDB
> > Inutile de prévoir de la tolérance de panne pour TempDB.
> > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
chaque
> > démarrage de SQL Server
> >
> > 4) Un RAID 5 pour les data
> >
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> > TETRASET
> > 75015 Paris
> > "Sebastien" <sebastien.dubosc.no.sp.am@m6net.fr> wrote in message
> > news:O#3w64x#DHA.3184@TK2MSFTNGP09.phx.gbl...
> > > Bonjour / Bonsoir,
> > >
> > > Une question technique concernant les disques
> > >
> > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> actuellement
> > > avec des disques en RAID5 (6x32Go) uniquement
> > > Il contient une base de 60Go environ, non journalisée, et quelques
> autres
> > > bases journalisées mais de 100/200Mo maxi.
> > > Par moment, lorsque certains utilisateurs font de méga requetes
d'insert
> > sur
> > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
aussi
> > > bien qu'en écriture. Idem lors de la création d'index clustered par
> > exemple.
> > > Est-ce que si les journaux de transactions et la tempdb étaient sur
> > d'autres
> > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> que
> > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > >
> > > Merci d'avance
> > > Sébastien
> > >
> >
> >
>
>
> Les logs me semblent plus importantes que les data.
Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
prendre en compte.
Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
lecture
Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
moteur
Pour les données, c'est plutôt la lecture que l'on doit privilégier
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Vuillermet Jacques" wrote in message
news:Oamk9R4#
> Les logs me semblent plus importantes que les data.
> En cas de crash sur le disque data, les data non sauvegardées sont
> entièrement récupérables par full restore + logs, alors que rien ne
> de récupérer des logs non sauvegardés.
>
> Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
>
> Jacques.
>
>
> "Med Bouchenafa[MVP]" a écrit dans le message
> news: #JkQV23#
> > Puisque tu évolues vers une nouvelle machine, il faut prévoir
:
> >
> > 1) Un RAID 1 pour l' OS
> >
> > 2) Un autre RAID 1 pour les log
> > Les IO sur le log sont essentiellement séquentiels.
> > S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> > placer sur un RAID 1
> > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
> > Quoi qu'il en soit, il est toujours intéressant de mettre le log
> > part.
> >
> > 3) Un RAID 0 pour TempDB
> > Inutile de prévoir de la tolérance de panne pour TempDB.
> > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
chaque
> > démarrage de SQL Server
> >
> > 4) Un RAID 5 pour les data
> >
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> > TETRASET
> > 75015 Paris
> > "Sebastien" wrote in message
> > news:O#3w64x#
> > > Bonjour / Bonsoir,
> > >
> > > Une question technique concernant les disques
> > >
> > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> actuellement
> > > avec des disques en RAID5 (6x32Go) uniquement
> > > Il contient une base de 60Go environ, non journalisée, et quelques
> autres
> > > bases journalisées mais de 100/200Mo maxi.
> > > Par moment, lorsque certains utilisateurs font de méga requetes
d'insert
> > sur
> > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
aussi
> > > bien qu'en écriture. Idem lors de la création d'index clustered par
> > exemple.
> > > Est-ce que si les journaux de transactions et la tempdb étaient sur
> > d'autres
> > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> que
> > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > >
> > > Merci d'avance
> > > Sébastien
> > >
> >
> >
>
>
> Les logs me semblent plus importantes que les data.
Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
prendre en compte.
Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
lecture
Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
moteur
Pour les données, c'est plutôt la lecture que l'on doit privilégier
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Vuillermet Jacques" wrote in message
news:Oamk9R4#
> Les logs me semblent plus importantes que les data.
> En cas de crash sur le disque data, les data non sauvegardées sont
> entièrement récupérables par full restore + logs, alors que rien ne
> de récupérer des logs non sauvegardés.
>
> Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
>
> Jacques.
>
>
> "Med Bouchenafa[MVP]" a écrit dans le message
> news: #JkQV23#
> > Puisque tu évolues vers une nouvelle machine, il faut prévoir
:
> >
> > 1) Un RAID 1 pour l' OS
> >
> > 2) Un autre RAID 1 pour les log
> > Les IO sur le log sont essentiellement séquentiels.
> > S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> > placer sur un RAID 1
> > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
> > Quoi qu'il en soit, il est toujours intéressant de mettre le log
> > part.
> >
> > 3) Un RAID 0 pour TempDB
> > Inutile de prévoir de la tolérance de panne pour TempDB.
> > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
chaque
> > démarrage de SQL Server
> >
> > 4) Un RAID 5 pour les data
> >
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> > TETRASET
> > 75015 Paris
> > "Sebastien" wrote in message
> > news:O#3w64x#
> > > Bonjour / Bonsoir,
> > >
> > > Une question technique concernant les disques
> > >
> > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> actuellement
> > > avec des disques en RAID5 (6x32Go) uniquement
> > > Il contient une base de 60Go environ, non journalisée, et quelques
> autres
> > > bases journalisées mais de 100/200Mo maxi.
> > > Par moment, lorsque certains utilisateurs font de méga requetes
d'insert
> > sur
> > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
aussi
> > > bien qu'en écriture. Idem lors de la création d'index clustered par
> > exemple.
> > > Est-ce que si les journaux de transactions et la tempdb étaient sur
> > d'autres
> > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> que
> > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > >
> > > Merci d'avance
> > > Sébastien
> > >
> >
> >
>
>
> Les logs me semblent plus importantes que les data.
Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
prendre en compte.
Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
lecture
Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
moteur
Pour les données, c'est plutôt la lecture que l'on doit privilégier
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Vuillermet Jacques" <jvuillermet@no-spam.fr> wrote in message
news:Oamk9R4#DHA.792@TK2MSFTNGP11.phx.gbl...
> Les logs me semblent plus importantes que les data.
> En cas de crash sur le disque data, les data non sauvegardées sont
> entièrement récupérables par full restore + logs, alors que rien ne
> de récupérer des logs non sauvegardés.
>
> Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
>
> Jacques.
>
>
> "Med Bouchenafa[MVP]" <com.tetraset@bouchenafa> a écrit dans le message
> news: #JkQV23#DHA.2212@TK2MSFTNGP10.phx.gbl...
> > Puisque tu évolues vers une nouvelle machine, il faut prévoir
:
> >
> > 1) Un RAID 1 pour l' OS
> >
> > 2) Un autre RAID 1 pour les log
> > Les IO sur le log sont essentiellement séquentiels.
> > S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> > placer sur un RAID 1
> > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
> > Quoi qu'il en soit, il est toujours intéressant de mettre le log
> > part.
> >
> > 3) Un RAID 0 pour TempDB
> > Inutile de prévoir de la tolérance de panne pour TempDB.
> > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
chaque
> > démarrage de SQL Server
> >
> > 4) Un RAID 5 pour les data
> >
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> > TETRASET
> > 75015 Paris
> > "Sebastien" <sebastien.dubosc.no.sp.am@m6net.fr> wrote in message
> > news:O#3w64x#DHA.3184@TK2MSFTNGP09.phx.gbl...
> > > Bonjour / Bonsoir,
> > >
> > > Une question technique concernant les disques
> > >
> > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> actuellement
> > > avec des disques en RAID5 (6x32Go) uniquement
> > > Il contient une base de 60Go environ, non journalisée, et quelques
> autres
> > > bases journalisées mais de 100/200Mo maxi.
> > > Par moment, lorsque certains utilisateurs font de méga requetes
d'insert
> > sur
> > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
aussi
> > > bien qu'en écriture. Idem lors de la création d'index clustered par
> > exemple.
> > > Est-ce que si les journaux de transactions et la tempdb étaient sur
> > d'autres
> > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> que
> > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > >
> > > Merci d'avance
> > > Sébastien
> > >
> >
> >
>
>
> Les logs me semblent plus importantes que les data.
Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
prendre en compte.
Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
lecture
Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
moteur
Pour les données, c'est plutôt la lecture que l'on doit privilégier
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Vuillermet Jacques" wrote in message
news:Oamk9R4#
> Les logs me semblent plus importantes que les data.
> En cas de crash sur le disque data, les data non sauvegardées sont
> entièrement récupérables par full restore + logs, alors que rien ne
> de récupérer des logs non sauvegardés.
>
> Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
>
> Jacques.
>
>
> "Med Bouchenafa[MVP]" a écrit dans le message
> news: #JkQV23#
> > Puisque tu évolues vers une nouvelle machine, il faut prévoir
:
> >
> > 1) Un RAID 1 pour l' OS
> >
> > 2) Un autre RAID 1 pour les log
> > Les IO sur le log sont essentiellement séquentiels.
> > S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> > placer sur un RAID 1
> > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
> > Quoi qu'il en soit, il est toujours intéressant de mettre le log
> > part.
> >
> > 3) Un RAID 0 pour TempDB
> > Inutile de prévoir de la tolérance de panne pour TempDB.
> > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
chaque
> > démarrage de SQL Server
> >
> > 4) Un RAID 5 pour les data
> >
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> > TETRASET
> > 75015 Paris
> > "Sebastien" wrote in message
> > news:O#3w64x#
> > > Bonjour / Bonsoir,
> > >
> > > Une question technique concernant les disques
> > >
> > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> actuellement
> > > avec des disques en RAID5 (6x32Go) uniquement
> > > Il contient une base de 60Go environ, non journalisée, et quelques
> autres
> > > bases journalisées mais de 100/200Mo maxi.
> > > Par moment, lorsque certains utilisateurs font de méga requetes
d'insert
> > sur
> > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
aussi
> > > bien qu'en écriture. Idem lors de la création d'index clustered par
> > exemple.
> > > Est-ce que si les journaux de transactions et la tempdb étaient sur
> > d'autres
> > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> que
> > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > >
> > > Merci d'avance
> > > Sébastien
> > >
> >
> >
>
>
> Un crash du disque ne provoquerait-il pas le blocage complet du serveur ?
(ou est-il préférable d'avoir) plusieurs cartes RAID.
Merci à tous les 2 Med et Jacques pour vos réponses.
Mais la version de Med correspond plus à ce que je pensais sauf sur 2 points
:
1. un RAID 0 pour la tempdb ?
Un crash du disque ne provoquerait-il pas le blocage complet du serveur ?
2. Comme je le disais à l'origine, la base 60Go n'est pas journalisée. Elle
est surtout utilisée en lecture. Mais ça n'empêche pas que des requêtes
d'insert assez volumineux sont effectuées couramment , de même que des bcp.
Actuellement, ceux-ci posent problème car deviennent bloquant pour d'autres
écritures mais aussi lectures sur cette base et les autres. Est-ce que ce
genre de config pourrait résoudre ce problème ?
Questions complémentaires :
si on retient l'option RAID1 (système+log) + RAID5 (data), est-ce que ça
nécessite (ou est-il préférable d'avoir) plusieurs cartes RAID.
Et concernant la mémoire cache embarquée sur la ou les cartes, avez-vous des
préconisations sur sa quantité mini en fonction de la taille ou du nombre de
disques gérés.
Cordialement,
Sébastien
"Med Bouchenafa[MVP]" a écrit dans le message de
news:%23fSBcv4%
> > Les logs me semblent plus importantes que les data.
> Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
> prendre en compte.
> Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
> lecture
> Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
> moteur
> Pour les données, c'est plutôt la lecture que l'on doit privilégier
>
> --
> Bien cordialement
> Med Bouchenafa
> TETRASET
> 75015 Paris
>
> "Vuillermet Jacques" wrote in message
> news:Oamk9R4#
> > Les logs me semblent plus importantes que les data.
> > En cas de crash sur le disque data, les data non sauvegardées sont
> > entièrement récupérables par full restore + logs, alors que rien ne
permet
> > de récupérer des logs non sauvegardés.
> >
> > Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
> >
> > Jacques.
> >
> >
> > "Med Bouchenafa[MVP]" a écrit dans le message
de
> > news: #JkQV23#
> > > Puisque tu évolues vers une nouvelle machine, il faut prévoir
idéalement
> :
> > >
> > > 1) Un RAID 1 pour l' OS
> > >
> > > 2) Un autre RAID 1 pour les log
> > > Les IO sur le log sont essentiellement séquentiels.
> > > S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> > > placer sur un RAID 1
> > > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
log.
> > > Quoi qu'il en soit, il est toujours intéressant de mettre le log
à
> > > part.
> > >
> > > 3) Un RAID 0 pour TempDB
> > > Inutile de prévoir de la tolérance de panne pour TempDB.
> > > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
> chaque
> > > démarrage de SQL Server
> > >
> > > 4) Un RAID 5 pour les data
> > >
> > >
> > > --
> > > Bien cordialement
> > > Med Bouchenafa
> > > TETRASET
> > > 75015 Paris
> > > "Sebastien" wrote in message
> > > news:O#3w64x#
> > > > Bonjour / Bonsoir,
> > > >
> > > > Une question technique concernant les disques
> > > >
> > > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> > actuellement
> > > > avec des disques en RAID5 (6x32Go) uniquement
> > > > Il contient une base de 60Go environ, non journalisée, et quelques
> > autres
> > > > bases journalisées mais de 100/200Mo maxi.
> > > > Par moment, lorsque certains utilisateurs font de méga requetes
> d'insert
> > > sur
> > > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
> aussi
> > > > bien qu'en écriture. Idem lors de la création d'index clustered par
> > > exemple.
> > > > Est-ce que si les journaux de transactions et la tempdb étaient sur
> > > d'autres
> > > > disques, par exemple en miroir, ça améliorerait les choses. Ou
est-ce
> > que
> > > > c'est la carte RAID qui pourrait être trop lente (pas assez de
mémoire
> > > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > > >
> > > > Merci d'avance
> > > > Sébastien
> > > >
> > >
> > >
> >
> >
>
>
> Un crash du disque ne provoquerait-il pas le blocage complet du serveur ?
(ou est-il préférable d'avoir) plusieurs cartes RAID.
Merci à tous les 2 Med et Jacques pour vos réponses.
Mais la version de Med correspond plus à ce que je pensais sauf sur 2 points
:
1. un RAID 0 pour la tempdb ?
Un crash du disque ne provoquerait-il pas le blocage complet du serveur ?
2. Comme je le disais à l'origine, la base 60Go n'est pas journalisée. Elle
est surtout utilisée en lecture. Mais ça n'empêche pas que des requêtes
d'insert assez volumineux sont effectuées couramment , de même que des bcp.
Actuellement, ceux-ci posent problème car deviennent bloquant pour d'autres
écritures mais aussi lectures sur cette base et les autres. Est-ce que ce
genre de config pourrait résoudre ce problème ?
Questions complémentaires :
si on retient l'option RAID1 (système+log) + RAID5 (data), est-ce que ça
nécessite (ou est-il préférable d'avoir) plusieurs cartes RAID.
Et concernant la mémoire cache embarquée sur la ou les cartes, avez-vous des
préconisations sur sa quantité mini en fonction de la taille ou du nombre de
disques gérés.
Cordialement,
Sébastien
"Med Bouchenafa[MVP]" <com.tetraset@bouchenafa> a écrit dans le message de
news:%23fSBcv4%23DHA.1796@TK2MSFTNGP12.phx.gbl...
> > Les logs me semblent plus importantes que les data.
> Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
> prendre en compte.
> Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
> lecture
> Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
> moteur
> Pour les données, c'est plutôt la lecture que l'on doit privilégier
>
> --
> Bien cordialement
> Med Bouchenafa
> TETRASET
> 75015 Paris
>
> "Vuillermet Jacques" <jvuillermet@no-spam.fr> wrote in message
> news:Oamk9R4#DHA.792@TK2MSFTNGP11.phx.gbl...
> > Les logs me semblent plus importantes que les data.
> > En cas de crash sur le disque data, les data non sauvegardées sont
> > entièrement récupérables par full restore + logs, alors que rien ne
permet
> > de récupérer des logs non sauvegardés.
> >
> > Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
> >
> > Jacques.
> >
> >
> > "Med Bouchenafa[MVP]" <com.tetraset@bouchenafa> a écrit dans le message
de
> > news: #JkQV23#DHA.2212@TK2MSFTNGP10.phx.gbl...
> > > Puisque tu évolues vers une nouvelle machine, il faut prévoir
idéalement
> :
> > >
> > > 1) Un RAID 1 pour l' OS
> > >
> > > 2) Un autre RAID 1 pour les log
> > > Les IO sur le log sont essentiellement séquentiels.
> > > S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> > > placer sur un RAID 1
> > > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
log.
> > > Quoi qu'il en soit, il est toujours intéressant de mettre le log
à
> > > part.
> > >
> > > 3) Un RAID 0 pour TempDB
> > > Inutile de prévoir de la tolérance de panne pour TempDB.
> > > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
> chaque
> > > démarrage de SQL Server
> > >
> > > 4) Un RAID 5 pour les data
> > >
> > >
> > > --
> > > Bien cordialement
> > > Med Bouchenafa
> > > TETRASET
> > > 75015 Paris
> > > "Sebastien" <sebastien.dubosc.no.sp.am@m6net.fr> wrote in message
> > > news:O#3w64x#DHA.3184@TK2MSFTNGP09.phx.gbl...
> > > > Bonjour / Bonsoir,
> > > >
> > > > Une question technique concernant les disques
> > > >
> > > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> > actuellement
> > > > avec des disques en RAID5 (6x32Go) uniquement
> > > > Il contient une base de 60Go environ, non journalisée, et quelques
> > autres
> > > > bases journalisées mais de 100/200Mo maxi.
> > > > Par moment, lorsque certains utilisateurs font de méga requetes
> d'insert
> > > sur
> > > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
> aussi
> > > > bien qu'en écriture. Idem lors de la création d'index clustered par
> > > exemple.
> > > > Est-ce que si les journaux de transactions et la tempdb étaient sur
> > > d'autres
> > > > disques, par exemple en miroir, ça améliorerait les choses. Ou
est-ce
> > que
> > > > c'est la carte RAID qui pourrait être trop lente (pas assez de
mémoire
> > > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > > >
> > > > Merci d'avance
> > > > Sébastien
> > > >
> > >
> > >
> >
> >
>
>
> Un crash du disque ne provoquerait-il pas le blocage complet du serveur ?
(ou est-il préférable d'avoir) plusieurs cartes RAID.
Merci à tous les 2 Med et Jacques pour vos réponses.
Mais la version de Med correspond plus à ce que je pensais sauf sur 2 points
:
1. un RAID 0 pour la tempdb ?
Un crash du disque ne provoquerait-il pas le blocage complet du serveur ?
2. Comme je le disais à l'origine, la base 60Go n'est pas journalisée. Elle
est surtout utilisée en lecture. Mais ça n'empêche pas que des requêtes
d'insert assez volumineux sont effectuées couramment , de même que des bcp.
Actuellement, ceux-ci posent problème car deviennent bloquant pour d'autres
écritures mais aussi lectures sur cette base et les autres. Est-ce que ce
genre de config pourrait résoudre ce problème ?
Questions complémentaires :
si on retient l'option RAID1 (système+log) + RAID5 (data), est-ce que ça
nécessite (ou est-il préférable d'avoir) plusieurs cartes RAID.
Et concernant la mémoire cache embarquée sur la ou les cartes, avez-vous des
préconisations sur sa quantité mini en fonction de la taille ou du nombre de
disques gérés.
Cordialement,
Sébastien
"Med Bouchenafa[MVP]" a écrit dans le message de
news:%23fSBcv4%
> > Les logs me semblent plus importantes que les data.
> Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
> prendre en compte.
> Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
> lecture
> Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
> moteur
> Pour les données, c'est plutôt la lecture que l'on doit privilégier
>
> --
> Bien cordialement
> Med Bouchenafa
> TETRASET
> 75015 Paris
>
> "Vuillermet Jacques" wrote in message
> news:Oamk9R4#
> > Les logs me semblent plus importantes que les data.
> > En cas de crash sur le disque data, les data non sauvegardées sont
> > entièrement récupérables par full restore + logs, alors que rien ne
permet
> > de récupérer des logs non sauvegardés.
> >
> > Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
> >
> > Jacques.
> >
> >
> > "Med Bouchenafa[MVP]" a écrit dans le message
de
> > news: #JkQV23#
> > > Puisque tu évolues vers une nouvelle machine, il faut prévoir
idéalement
> :
> > >
> > > 1) Un RAID 1 pour l' OS
> > >
> > > 2) Un autre RAID 1 pour les log
> > > Les IO sur le log sont essentiellement séquentiels.
> > > S'il n'y a qu'un seul fichier de log, il serait intéressant de le
> > > placer sur un RAID 1
> > > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
log.
> > > Quoi qu'il en soit, il est toujours intéressant de mettre le log
à
> > > part.
> > >
> > > 3) Un RAID 0 pour TempDB
> > > Inutile de prévoir de la tolérance de panne pour TempDB.
> > > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
> chaque
> > > démarrage de SQL Server
> > >
> > > 4) Un RAID 5 pour les data
> > >
> > >
> > > --
> > > Bien cordialement
> > > Med Bouchenafa
> > > TETRASET
> > > 75015 Paris
> > > "Sebastien" wrote in message
> > > news:O#3w64x#
> > > > Bonjour / Bonsoir,
> > > >
> > > > Une question technique concernant les disques
> > > >
> > > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> > actuellement
> > > > avec des disques en RAID5 (6x32Go) uniquement
> > > > Il contient une base de 60Go environ, non journalisée, et quelques
> > autres
> > > > bases journalisées mais de 100/200Mo maxi.
> > > > Par moment, lorsque certains utilisateurs font de méga requetes
> d'insert
> > > sur
> > > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en lecture
> aussi
> > > > bien qu'en écriture. Idem lors de la création d'index clustered par
> > > exemple.
> > > > Est-ce que si les journaux de transactions et la tempdb étaient sur
> > > d'autres
> > > > disques, par exemple en miroir, ça améliorerait les choses. Ou
est-ce
> > que
> > > > c'est la carte RAID qui pourrait être trop lente (pas assez de
mémoire
> > > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > > >
> > > > Merci d'avance
> > > > Sébastien
> > > >
> > >
> > >
> >
> >
>
>
> > Un crash du disque ne provoquerait-il pas le blocage complet du serveur
C'est exact. Je n'y avais pas pensé.
> 2..... la base 60Go n'est pas journalisée....
Que la base soit journalisée ou pas, SQL Server passe toujours par le
D'autre part, même si j'ignore tout de ton contexte, je pense que les
actuellement ne seraient pas résolus brusquement par la nouvelle
commencer à chercher une solution dans le plan d'indexage et de
> Un crash du disque ne provoquerait-il pas le blocage complet du serveur
C'est exact. Je n'y avais pas pensé.
.
> 2..... la base 60Go n'est pas journalisée....
Que la base soit journalisée ou pas, SQL Server passe toujours par le
D'autre part, même si j'ignore tout de ton contexte, je pense que les
actuellement ne seraient pas résolus brusquement par la nouvelle
commencer à chercher une solution dans le plan d'indexage et de
> (ou est-il préférable d'avoir) plusieurs cartes RAID.
La capacité IO des cartes actuelles fait qu'elles sont capables de
derrière.
A mon avis, il faut investiguer cette piste tout en dernier et se
requêtes
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Sebastien" a écrit dans le message
#mVxwt9#
> Merci à tous les 2 Med et Jacques pour vos réponses.
> Mais la version de Med correspond plus à ce que je pensais sauf sur 2
> :
>
> 1. un RAID 0 pour la tempdb ?
> Un crash du disque ne provoquerait-il pas le blocage complet du serveur
>
> 2. Comme je le disais à l'origine, la base 60Go n'est pas journalisée.
> est surtout utilisée en lecture. Mais ça n'empêche pas que des requêtes
> d'insert assez volumineux sont effectuées couramment , de même que des
> Actuellement, ceux-ci posent problème car deviennent bloquant pour
> écritures mais aussi lectures sur cette base et les autres. Est-ce que
> genre de config pourrait résoudre ce problème ?
>
> Questions complémentaires :
> si on retient l'option RAID1 (système+log) + RAID5 (data), est-ce que ça
> nécessite (ou est-il préférable d'avoir) plusieurs cartes RAID.
> Et concernant la mémoire cache embarquée sur la ou les cartes, avez-vous
> préconisations sur sa quantité mini en fonction de la taille ou du
> disques gérés.
>
> Cordialement,
> Sébastien
>
> "Med Bouchenafa[MVP]" a écrit dans le message
> news:%23fSBcv4%
> > > Les logs me semblent plus importantes que les data.
> > Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
> > prendre en compte.
> > Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
> > lecture
> > Pour le log, on doit privilégier l'écriture pour libérer au plus vite
> > moteur
> > Pour les données, c'est plutôt la lecture que l'on doit privilégier
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> > TETRASET
> > 75015 Paris
> >
> > "Vuillermet Jacques" wrote in message
> > news:Oamk9R4#
> > > Les logs me semblent plus importantes que les data.
> > > En cas de crash sur le disque data, les data non sauvegardées sont
> > > entièrement récupérables par full restore + logs, alors que rien ne
> permet
> > > de récupérer des logs non sauvegardés.
> > >
> > > Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
> > >
> > > Jacques.
> > >
> > > "Med Bouchenafa[MVP]" a écrit dans le
> de
> > > news: #JkQV23#
> > > > Puisque tu évolues vers une nouvelle machine, il faut prévoir
> idéalement
> > :
> > > >
> > > > 1) Un RAID 1 pour l' OS
> > > >
> > > > 2) Un autre RAID 1 pour les log
> > > > Les IO sur le log sont essentiellement séquentiels.
> > > > S'il n'y a qu'un seul fichier de log, il serait intéressant
> > > > placer sur un RAID 1
> > > > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
> log.
> > > > Quoi qu'il en soit, il est toujours intéressant de mettre le
> à
> > > > part.
> > > >
> > > > 3) Un RAID 0 pour TempDB
> > > > Inutile de prévoir de la tolérance de panne pour TempDB.
> > > > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
> > chaque
> > > > démarrage de SQL Server
> > > >
> > > > 4) Un RAID 5 pour les data
> > > > --
> > > > Bien cordialement
> > > > Med Bouchenafa
> > > > TETRASET
> > > > 75015 Paris
> > > > "Sebastien" wrote in message
> > > > news:O#3w64x#
> > > > > Bonjour / Bonsoir,
> > > > > Une question technique concernant les disques
> > > > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> > > actuellement
> > > > > avec des disques en RAID5 (6x32Go) uniquement
> > > > > Il contient une base de 60Go environ, non journalisée, et
> > > autres
> > > > > bases journalisées mais de 100/200Mo maxi.
> > > > > Par moment, lorsque certains utilisateurs font de méga requetes
> > d'insert
> > > > sur
> > > > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en
> > aussi
> > > > > bien qu'en écriture. Idem lors de la création d'index clustered
> > > > exemple.
> > > > > Est-ce que si les journaux de transactions et la tempdb étaient
> > > > d'autres
> > > > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> est-ce
> > > que
> > > > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> mémoire
> > > > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > > > >
> > > > > Merci d'avance
> > > > > Sébastien
> > Un crash du disque ne provoquerait-il pas le blocage complet du serveur
C'est exact. Je n'y avais pas pensé.
> 2..... la base 60Go n'est pas journalisée....
Que la base soit journalisée ou pas, SQL Server passe toujours par le
D'autre part, même si j'ignore tout de ton contexte, je pense que les
actuellement ne seraient pas résolus brusquement par la nouvelle
commencer à chercher une solution dans le plan d'indexage et de
> Un crash du disque ne provoquerait-il pas le blocage complet du serveur
C'est exact. Je n'y avais pas pensé.
.
> 2..... la base 60Go n'est pas journalisée....
Que la base soit journalisée ou pas, SQL Server passe toujours par le
D'autre part, même si j'ignore tout de ton contexte, je pense que les
actuellement ne seraient pas résolus brusquement par la nouvelle
commencer à chercher une solution dans le plan d'indexage et de
> (ou est-il préférable d'avoir) plusieurs cartes RAID.
La capacité IO des cartes actuelles fait qu'elles sont capables de
derrière.
A mon avis, il faut investiguer cette piste tout en dernier et se
requêtes
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Sebastien" <sebastien.dubosc.no.sp.am@m6net.fr> a écrit dans le message
#mVxwt9#DHA.808@TK2MSFTNGP12.phx.gbl...
> Merci à tous les 2 Med et Jacques pour vos réponses.
> Mais la version de Med correspond plus à ce que je pensais sauf sur 2
> :
>
> 1. un RAID 0 pour la tempdb ?
> Un crash du disque ne provoquerait-il pas le blocage complet du serveur
>
> 2. Comme je le disais à l'origine, la base 60Go n'est pas journalisée.
> est surtout utilisée en lecture. Mais ça n'empêche pas que des requêtes
> d'insert assez volumineux sont effectuées couramment , de même que des
> Actuellement, ceux-ci posent problème car deviennent bloquant pour
> écritures mais aussi lectures sur cette base et les autres. Est-ce que
> genre de config pourrait résoudre ce problème ?
>
> Questions complémentaires :
> si on retient l'option RAID1 (système+log) + RAID5 (data), est-ce que ça
> nécessite (ou est-il préférable d'avoir) plusieurs cartes RAID.
> Et concernant la mémoire cache embarquée sur la ou les cartes, avez-vous
> préconisations sur sa quantité mini en fonction de la taille ou du
> disques gérés.
>
> Cordialement,
> Sébastien
>
> "Med Bouchenafa[MVP]" <com.tetraset@bouchenafa> a écrit dans le message
> news:%23fSBcv4%23DHA.1796@TK2MSFTNGP12.phx.gbl...
> > > Les logs me semblent plus importantes que les data.
> > Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
> > prendre en compte.
> > Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
> > lecture
> > Pour le log, on doit privilégier l'écriture pour libérer au plus vite
> > moteur
> > Pour les données, c'est plutôt la lecture que l'on doit privilégier
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> > TETRASET
> > 75015 Paris
> >
> > "Vuillermet Jacques" <jvuillermet@no-spam.fr> wrote in message
> > news:Oamk9R4#DHA.792@TK2MSFTNGP11.phx.gbl...
> > > Les logs me semblent plus importantes que les data.
> > > En cas de crash sur le disque data, les data non sauvegardées sont
> > > entièrement récupérables par full restore + logs, alors que rien ne
> permet
> > > de récupérer des logs non sauvegardés.
> > >
> > > Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
> > >
> > > Jacques.
> > >
> > > "Med Bouchenafa[MVP]" <com.tetraset@bouchenafa> a écrit dans le
> de
> > > news: #JkQV23#DHA.2212@TK2MSFTNGP10.phx.gbl...
> > > > Puisque tu évolues vers une nouvelle machine, il faut prévoir
> idéalement
> > :
> > > >
> > > > 1) Un RAID 1 pour l' OS
> > > >
> > > > 2) Un autre RAID 1 pour les log
> > > > Les IO sur le log sont essentiellement séquentiels.
> > > > S'il n'y a qu'un seul fichier de log, il serait intéressant
> > > > placer sur un RAID 1
> > > > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
> log.
> > > > Quoi qu'il en soit, il est toujours intéressant de mettre le
> à
> > > > part.
> > > >
> > > > 3) Un RAID 0 pour TempDB
> > > > Inutile de prévoir de la tolérance de panne pour TempDB.
> > > > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
> > chaque
> > > > démarrage de SQL Server
> > > >
> > > > 4) Un RAID 5 pour les data
> > > > --
> > > > Bien cordialement
> > > > Med Bouchenafa
> > > > TETRASET
> > > > 75015 Paris
> > > > "Sebastien" <sebastien.dubosc.no.sp.am@m6net.fr> wrote in message
> > > > news:O#3w64x#DHA.3184@TK2MSFTNGP09.phx.gbl...
> > > > > Bonjour / Bonsoir,
> > > > > Une question technique concernant les disques
> > > > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> > > actuellement
> > > > > avec des disques en RAID5 (6x32Go) uniquement
> > > > > Il contient une base de 60Go environ, non journalisée, et
> > > autres
> > > > > bases journalisées mais de 100/200Mo maxi.
> > > > > Par moment, lorsque certains utilisateurs font de méga requetes
> > d'insert
> > > > sur
> > > > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en
> > aussi
> > > > > bien qu'en écriture. Idem lors de la création d'index clustered
> > > > exemple.
> > > > > Est-ce que si les journaux de transactions et la tempdb étaient
> > > > d'autres
> > > > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> est-ce
> > > que
> > > > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> mémoire
> > > > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > > > >
> > > > > Merci d'avance
> > > > > Sébastien
> > Un crash du disque ne provoquerait-il pas le blocage complet du serveur
C'est exact. Je n'y avais pas pensé.
> 2..... la base 60Go n'est pas journalisée....
Que la base soit journalisée ou pas, SQL Server passe toujours par le
D'autre part, même si j'ignore tout de ton contexte, je pense que les
actuellement ne seraient pas résolus brusquement par la nouvelle
commencer à chercher une solution dans le plan d'indexage et de
> Un crash du disque ne provoquerait-il pas le blocage complet du serveur
C'est exact. Je n'y avais pas pensé.
.
> 2..... la base 60Go n'est pas journalisée....
Que la base soit journalisée ou pas, SQL Server passe toujours par le
D'autre part, même si j'ignore tout de ton contexte, je pense que les
actuellement ne seraient pas résolus brusquement par la nouvelle
commencer à chercher une solution dans le plan d'indexage et de
> (ou est-il préférable d'avoir) plusieurs cartes RAID.
La capacité IO des cartes actuelles fait qu'elles sont capables de
derrière.
A mon avis, il faut investiguer cette piste tout en dernier et se
requêtes
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"Sebastien" a écrit dans le message
#mVxwt9#
> Merci à tous les 2 Med et Jacques pour vos réponses.
> Mais la version de Med correspond plus à ce que je pensais sauf sur 2
> :
>
> 1. un RAID 0 pour la tempdb ?
> Un crash du disque ne provoquerait-il pas le blocage complet du serveur
>
> 2. Comme je le disais à l'origine, la base 60Go n'est pas journalisée.
> est surtout utilisée en lecture. Mais ça n'empêche pas que des requêtes
> d'insert assez volumineux sont effectuées couramment , de même que des
> Actuellement, ceux-ci posent problème car deviennent bloquant pour
> écritures mais aussi lectures sur cette base et les autres. Est-ce que
> genre de config pourrait résoudre ce problème ?
>
> Questions complémentaires :
> si on retient l'option RAID1 (système+log) + RAID5 (data), est-ce que ça
> nécessite (ou est-il préférable d'avoir) plusieurs cartes RAID.
> Et concernant la mémoire cache embarquée sur la ou les cartes, avez-vous
> préconisations sur sa quantité mini en fonction de la taille ou du
> disques gérés.
>
> Cordialement,
> Sébastien
>
> "Med Bouchenafa[MVP]" a écrit dans le message
> news:%23fSBcv4%
> > > Les logs me semblent plus importantes que les data.
> > Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
> > prendre en compte.
> > Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
> > lecture
> > Pour le log, on doit privilégier l'écriture pour libérer au plus vite
> > moteur
> > Pour les données, c'est plutôt la lecture que l'on doit privilégier
> >
> > --
> > Bien cordialement
> > Med Bouchenafa
> > TETRASET
> > 75015 Paris
> >
> > "Vuillermet Jacques" wrote in message
> > news:Oamk9R4#
> > > Les logs me semblent plus importantes que les data.
> > > En cas de crash sur le disque data, les data non sauvegardées sont
> > > entièrement récupérables par full restore + logs, alors que rien ne
> permet
> > > de récupérer des logs non sauvegardés.
> > >
> > > Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
> > >
> > > Jacques.
> > >
> > > "Med Bouchenafa[MVP]" a écrit dans le
> de
> > > news: #JkQV23#
> > > > Puisque tu évolues vers une nouvelle machine, il faut prévoir
> idéalement
> > :
> > > >
> > > > 1) Un RAID 1 pour l' OS
> > > >
> > > > 2) Un autre RAID 1 pour les log
> > > > Les IO sur le log sont essentiellement séquentiels.
> > > > S'il n'y a qu'un seul fichier de log, il serait intéressant
> > > > placer sur un RAID 1
> > > > L'avantage s'estompe quelque peu s'il y a plusieurs fichiers
> log.
> > > > Quoi qu'il en soit, il est toujours intéressant de mettre le
> à
> > > > part.
> > > >
> > > > 3) Un RAID 0 pour TempDB
> > > > Inutile de prévoir de la tolérance de panne pour TempDB.
> > > > Elle peut se contenter d'un RAID 0 car elle est reconstruite à
> > chaque
> > > > démarrage de SQL Server
> > > >
> > > > 4) Un RAID 5 pour les data
> > > > --
> > > > Bien cordialement
> > > > Med Bouchenafa
> > > > TETRASET
> > > > 75015 Paris
> > > > "Sebastien" wrote in message
> > > > news:O#3w64x#
> > > > > Bonjour / Bonsoir,
> > > > > Une question technique concernant les disques
> > > > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> > > actuellement
> > > > > avec des disques en RAID5 (6x32Go) uniquement
> > > > > Il contient une base de 60Go environ, non journalisée, et
> > > autres
> > > > > bases journalisées mais de 100/200Mo maxi.
> > > > > Par moment, lorsque certains utilisateurs font de méga requetes
> > d'insert
> > > > sur
> > > > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en
> > aussi
> > > > > bien qu'en écriture. Idem lors de la création d'index clustered
> > > > exemple.
> > > > > Est-ce que si les journaux de transactions et la tempdb étaient
> > > > d'autres
> > > > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> est-ce
> > > que
> > > > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> mémoire
> > > > > cache? (32 Mo)) ou les disques qui pourraient être trop lent. ?
> > > > >
> > > > > Merci d'avance
> > > > > Sébastien
Les logs me semblent plus importantes que les data.
Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
prendre en compte.
Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
lecture
Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
moteur
Pour les données, c'est plutôt la lecture que l'on doit privilégier
Les logs me semblent plus importantes que les data.
Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
prendre en compte.
Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
lecture
Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
moteur
Pour les données, c'est plutôt la lecture que l'on doit privilégier
Les logs me semblent plus importantes que les data.
Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
prendre en compte.
Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
lecture
Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
moteur
Pour les données, c'est plutôt la lecture que l'on doit privilégier
> Ca ressemble quand même à une saturation des IO au moment de l'écriture.
Ca se défragmente une base ?
> > Un crash du disque ne provoquerait-il pas le blocage complet du
?
> C'est exact. Je n'y avais pas pensé.
Je préfère ça ;-) Donc la tempdb plutôt sur le RAID1.
> > 2..... la base 60Go n'est pas journalisée....
> Que la base soit journalisée ou pas, SQL Server passe toujours par le
journal.
> D'autre part, même si j'ignore tout de ton contexte, je pense que les
problèmes rencontrés
> actuellement ne seraient pas résolus brusquement par la nouvelle
architecture matérielle. Il faut
> commencer à chercher une solution dans le plan d'indexage et de
verrouillage actuels.
Déjà fait ! Le problème, c'est que je ne vois pas ce que viendrait faire
plan d'indexage dans l'exécution d'un bcp sur une table vierge, la
d'un index clustered unique ou un insert énorme dans une table vierge (le
select uniquement permettant l'insert lui fonctionnant très bien sans
blocage des autres connexions).
Ca ressemble quand même à une saturation des IO au moment de l'écriture.
Ca se défragmente une base ? un RAID 5 ?
Sébastien
"Med Bouchenafa[MVP]" a écrit dans le message de
news:Omht5bH$
> > Un crash du disque ne provoquerait-il pas le blocage complet du
?
> C'est exact. Je n'y avais pas pensé.
> .
> > 2..... la base 60Go n'est pas journalisée....
> Que la base soit journalisée ou pas, SQL Server passe toujours par le
journal.
> D'autre part, même si j'ignore tout de ton contexte, je pense que les
problèmes rencontrés
> actuellement ne seraient pas résolus brusquement par la nouvelle
architecture matérielle. Il faut
> commencer à chercher une solution dans le plan d'indexage et de
verrouillage actuels.
>
> > (ou est-il préférable d'avoir) plusieurs cartes RAID.
> La capacité IO des cartes actuelles fait qu'elles sont capables de
desservir plusieurs disques
> derrière.
> A mon avis, il faut investiguer cette piste tout en dernier et se
concentrer sur l'amélioration des
> requêtes
>
> --
> Bien cordialement
> Med Bouchenafa
> TETRASET
> 75015 Paris
>
> "Sebastien" a écrit dans le message
de news:
> #mVxwt9#
> > Merci à tous les 2 Med et Jacques pour vos réponses.
> > Mais la version de Med correspond plus à ce que je pensais sauf sur 2
points
> > :
> >
> > 1. un RAID 0 pour la tempdb ?
> > Un crash du disque ne provoquerait-il pas le blocage complet du
?
> >
> > 2. Comme je le disais à l'origine, la base 60Go n'est pas journalisée.
Elle
> > est surtout utilisée en lecture. Mais ça n'empêche pas que des
> > d'insert assez volumineux sont effectuées couramment , de même que des
bcp.
> > Actuellement, ceux-ci posent problème car deviennent bloquant pour
d'autres
> > écritures mais aussi lectures sur cette base et les autres. Est-ce que
ce
> > genre de config pourrait résoudre ce problème ?
> >
> > Questions complémentaires :
> > si on retient l'option RAID1 (système+log) + RAID5 (data), est-ce que
> > nécessite (ou est-il préférable d'avoir) plusieurs cartes RAID.
> > Et concernant la mémoire cache embarquée sur la ou les cartes,
des
> > préconisations sur sa quantité mini en fonction de la taille ou du
nombre de
> > disques gérés.
> >
> > Cordialement,
> > Sébastien
> >
> > "Med Bouchenafa[MVP]" a écrit dans le
de
> > news:%23fSBcv4%
> > > > Les logs me semblent plus importantes que les data.
> > > Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes
> > > prendre en compte.
> > > Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse
> > > lecture
> > > Pour le log, on doit privilégier l'écriture pour libérer au plus
le
> > > moteur
> > > Pour les données, c'est plutôt la lecture que l'on doit privilégier
> > >
> > > --
> > > Bien cordialement
> > > Med Bouchenafa
> > > TETRASET
> > > 75015 Paris
> > >
> > > "Vuillermet Jacques" wrote in message
> > > news:Oamk9R4#
> > > > Les logs me semblent plus importantes que les data.
> > > > En cas de crash sur le disque data, les data non sauvegardées sont
> > > > entièrement récupérables par full restore + logs, alors que rien
> > permet
> > > > de récupérer des logs non sauvegardés.
> > > >
> > > > Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
> > > >
> > > > Jacques.
> > > >
> > > > "Med Bouchenafa[MVP]" a écrit dans le
message
> > de
> > > > news: #JkQV23#
> > > > > Puisque tu évolues vers une nouvelle machine, il faut prévoir
> > idéalement
> > > :
> > > > >
> > > > > 1) Un RAID 1 pour l' OS
> > > > >
> > > > > 2) Un autre RAID 1 pour les log
> > > > > Les IO sur le log sont essentiellement séquentiels.
> > > > > S'il n'y a qu'un seul fichier de log, il serait intéressant
de le
> > > > > placer sur un RAID 1
> > > > > L'avantage s'estompe quelque peu s'il y a plusieurs
> > log.
> > > > > Quoi qu'il en soit, il est toujours intéressant de mettre
log
> > à
> > > > > part.
> > > > >
> > > > > 3) Un RAID 0 pour TempDB
> > > > > Inutile de prévoir de la tolérance de panne pour TempDB.
> > > > > Elle peut se contenter d'un RAID 0 car elle est reconstruite
> > > chaque
> > > > > démarrage de SQL Server
> > > > >
> > > > > 4) Un RAID 5 pour les data
> > > > > --
> > > > > Bien cordialement
> > > > > Med Bouchenafa
> > > > > TETRASET
> > > > > 75015 Paris
> > > > > "Sebastien" wrote in
> > > > > news:O#3w64x#
> > > > > > Bonjour / Bonsoir,
> > > > > > Une question technique concernant les disques
> > > > > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> > > > actuellement
> > > > > > avec des disques en RAID5 (6x32Go) uniquement
> > > > > > Il contient une base de 60Go environ, non journalisée, et
quelques
> > > > autres
> > > > > > bases journalisées mais de 100/200Mo maxi.
> > > > > > Par moment, lorsque certains utilisateurs font de méga
> > > d'insert
> > > > > sur
> > > > > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en
lecture
> > > aussi
> > > > > > bien qu'en écriture. Idem lors de la création d'index
par
> > > > > exemple.
> > > > > > Est-ce que si les journaux de transactions et la tempdb
sur
> > > > > d'autres
> > > > > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> > est-ce
> > > > que
> > > > > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> > mémoire
> > > > > > cache? (32 Mo)) ou les disques qui pourraient être trop lent.
> > > > > >
> > > > > > Merci d'avance
> > > > > > Sébastien
> Ca ressemble quand même à une saturation des IO au moment de l'écriture.
Ca se défragmente une base ?
> > Un crash du disque ne provoquerait-il pas le blocage complet du
?
> C'est exact. Je n'y avais pas pensé.
Je préfère ça ;-) Donc la tempdb plutôt sur le RAID1.
> > 2..... la base 60Go n'est pas journalisée....
> Que la base soit journalisée ou pas, SQL Server passe toujours par le
journal.
> D'autre part, même si j'ignore tout de ton contexte, je pense que les
problèmes rencontrés
> actuellement ne seraient pas résolus brusquement par la nouvelle
architecture matérielle. Il faut
> commencer à chercher une solution dans le plan d'indexage et de
verrouillage actuels.
Déjà fait ! Le problème, c'est que je ne vois pas ce que viendrait faire
plan d'indexage dans l'exécution d'un bcp sur une table vierge, la
d'un index clustered unique ou un insert énorme dans une table vierge (le
select uniquement permettant l'insert lui fonctionnant très bien sans
blocage des autres connexions).
Ca ressemble quand même à une saturation des IO au moment de l'écriture.
Ca se défragmente une base ? un RAID 5 ?
Sébastien
"Med Bouchenafa[MVP]" <com.tetraset@Bouchenafa> a écrit dans le message de
news:Omht5bH$DHA.1844@TK2MSFTNGP11.phx.gbl...
> > Un crash du disque ne provoquerait-il pas le blocage complet du
?
> C'est exact. Je n'y avais pas pensé.
> .
> > 2..... la base 60Go n'est pas journalisée....
> Que la base soit journalisée ou pas, SQL Server passe toujours par le
journal.
> D'autre part, même si j'ignore tout de ton contexte, je pense que les
problèmes rencontrés
> actuellement ne seraient pas résolus brusquement par la nouvelle
architecture matérielle. Il faut
> commencer à chercher une solution dans le plan d'indexage et de
verrouillage actuels.
>
> > (ou est-il préférable d'avoir) plusieurs cartes RAID.
> La capacité IO des cartes actuelles fait qu'elles sont capables de
desservir plusieurs disques
> derrière.
> A mon avis, il faut investiguer cette piste tout en dernier et se
concentrer sur l'amélioration des
> requêtes
>
> --
> Bien cordialement
> Med Bouchenafa
> TETRASET
> 75015 Paris
>
> "Sebastien" <sebastien.dubosc.no.sp.am@m6net.fr> a écrit dans le message
de news:
> #mVxwt9#DHA.808@TK2MSFTNGP12.phx.gbl...
> > Merci à tous les 2 Med et Jacques pour vos réponses.
> > Mais la version de Med correspond plus à ce que je pensais sauf sur 2
points
> > :
> >
> > 1. un RAID 0 pour la tempdb ?
> > Un crash du disque ne provoquerait-il pas le blocage complet du
?
> >
> > 2. Comme je le disais à l'origine, la base 60Go n'est pas journalisée.
Elle
> > est surtout utilisée en lecture. Mais ça n'empêche pas que des
> > d'insert assez volumineux sont effectuées couramment , de même que des
bcp.
> > Actuellement, ceux-ci posent problème car deviennent bloquant pour
d'autres
> > écritures mais aussi lectures sur cette base et les autres. Est-ce que
ce
> > genre de config pourrait résoudre ce problème ?
> >
> > Questions complémentaires :
> > si on retient l'option RAID1 (système+log) + RAID5 (data), est-ce que
> > nécessite (ou est-il préférable d'avoir) plusieurs cartes RAID.
> > Et concernant la mémoire cache embarquée sur la ou les cartes,
des
> > préconisations sur sa quantité mini en fonction de la taille ou du
nombre de
> > disques gérés.
> >
> > Cordialement,
> > Sébastien
> >
> > "Med Bouchenafa[MVP]" <com.tetraset@bouchenafa> a écrit dans le
de
> > news:%23fSBcv4%23DHA.1796@TK2MSFTNGP12.phx.gbl...
> > > > Les logs me semblent plus importantes que les data.
> > > Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes
> > > prendre en compte.
> > > Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse
> > > lecture
> > > Pour le log, on doit privilégier l'écriture pour libérer au plus
le
> > > moteur
> > > Pour les données, c'est plutôt la lecture que l'on doit privilégier
> > >
> > > --
> > > Bien cordialement
> > > Med Bouchenafa
> > > TETRASET
> > > 75015 Paris
> > >
> > > "Vuillermet Jacques" <jvuillermet@no-spam.fr> wrote in message
> > > news:Oamk9R4#DHA.792@TK2MSFTNGP11.phx.gbl...
> > > > Les logs me semblent plus importantes que les data.
> > > > En cas de crash sur le disque data, les data non sauvegardées sont
> > > > entièrement récupérables par full restore + logs, alors que rien
> > permet
> > > > de récupérer des logs non sauvegardés.
> > > >
> > > > Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
> > > >
> > > > Jacques.
> > > >
> > > > "Med Bouchenafa[MVP]" <com.tetraset@bouchenafa> a écrit dans le
message
> > de
> > > > news: #JkQV23#DHA.2212@TK2MSFTNGP10.phx.gbl...
> > > > > Puisque tu évolues vers une nouvelle machine, il faut prévoir
> > idéalement
> > > :
> > > > >
> > > > > 1) Un RAID 1 pour l' OS
> > > > >
> > > > > 2) Un autre RAID 1 pour les log
> > > > > Les IO sur le log sont essentiellement séquentiels.
> > > > > S'il n'y a qu'un seul fichier de log, il serait intéressant
de le
> > > > > placer sur un RAID 1
> > > > > L'avantage s'estompe quelque peu s'il y a plusieurs
> > log.
> > > > > Quoi qu'il en soit, il est toujours intéressant de mettre
log
> > à
> > > > > part.
> > > > >
> > > > > 3) Un RAID 0 pour TempDB
> > > > > Inutile de prévoir de la tolérance de panne pour TempDB.
> > > > > Elle peut se contenter d'un RAID 0 car elle est reconstruite
> > > chaque
> > > > > démarrage de SQL Server
> > > > >
> > > > > 4) Un RAID 5 pour les data
> > > > > --
> > > > > Bien cordialement
> > > > > Med Bouchenafa
> > > > > TETRASET
> > > > > 75015 Paris
> > > > > "Sebastien" <sebastien.dubosc.no.sp.am@m6net.fr> wrote in
> > > > > news:O#3w64x#DHA.3184@TK2MSFTNGP09.phx.gbl...
> > > > > > Bonjour / Bonsoir,
> > > > > > Une question technique concernant les disques
> > > > > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> > > > actuellement
> > > > > > avec des disques en RAID5 (6x32Go) uniquement
> > > > > > Il contient une base de 60Go environ, non journalisée, et
quelques
> > > > autres
> > > > > > bases journalisées mais de 100/200Mo maxi.
> > > > > > Par moment, lorsque certains utilisateurs font de méga
> > > d'insert
> > > > > sur
> > > > > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en
lecture
> > > aussi
> > > > > > bien qu'en écriture. Idem lors de la création d'index
par
> > > > > exemple.
> > > > > > Est-ce que si les journaux de transactions et la tempdb
sur
> > > > > d'autres
> > > > > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> > est-ce
> > > > que
> > > > > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> > mémoire
> > > > > > cache? (32 Mo)) ou les disques qui pourraient être trop lent.
> > > > > >
> > > > > > Merci d'avance
> > > > > > Sébastien
> Ca ressemble quand même à une saturation des IO au moment de l'écriture.
Ca se défragmente une base ?
> > Un crash du disque ne provoquerait-il pas le blocage complet du
?
> C'est exact. Je n'y avais pas pensé.
Je préfère ça ;-) Donc la tempdb plutôt sur le RAID1.
> > 2..... la base 60Go n'est pas journalisée....
> Que la base soit journalisée ou pas, SQL Server passe toujours par le
journal.
> D'autre part, même si j'ignore tout de ton contexte, je pense que les
problèmes rencontrés
> actuellement ne seraient pas résolus brusquement par la nouvelle
architecture matérielle. Il faut
> commencer à chercher une solution dans le plan d'indexage et de
verrouillage actuels.
Déjà fait ! Le problème, c'est que je ne vois pas ce que viendrait faire
plan d'indexage dans l'exécution d'un bcp sur une table vierge, la
d'un index clustered unique ou un insert énorme dans une table vierge (le
select uniquement permettant l'insert lui fonctionnant très bien sans
blocage des autres connexions).
Ca ressemble quand même à une saturation des IO au moment de l'écriture.
Ca se défragmente une base ? un RAID 5 ?
Sébastien
"Med Bouchenafa[MVP]" a écrit dans le message de
news:Omht5bH$
> > Un crash du disque ne provoquerait-il pas le blocage complet du
?
> C'est exact. Je n'y avais pas pensé.
> .
> > 2..... la base 60Go n'est pas journalisée....
> Que la base soit journalisée ou pas, SQL Server passe toujours par le
journal.
> D'autre part, même si j'ignore tout de ton contexte, je pense que les
problèmes rencontrés
> actuellement ne seraient pas résolus brusquement par la nouvelle
architecture matérielle. Il faut
> commencer à chercher une solution dans le plan d'indexage et de
verrouillage actuels.
>
> > (ou est-il préférable d'avoir) plusieurs cartes RAID.
> La capacité IO des cartes actuelles fait qu'elles sont capables de
desservir plusieurs disques
> derrière.
> A mon avis, il faut investiguer cette piste tout en dernier et se
concentrer sur l'amélioration des
> requêtes
>
> --
> Bien cordialement
> Med Bouchenafa
> TETRASET
> 75015 Paris
>
> "Sebastien" a écrit dans le message
de news:
> #mVxwt9#
> > Merci à tous les 2 Med et Jacques pour vos réponses.
> > Mais la version de Med correspond plus à ce que je pensais sauf sur 2
points
> > :
> >
> > 1. un RAID 0 pour la tempdb ?
> > Un crash du disque ne provoquerait-il pas le blocage complet du
?
> >
> > 2. Comme je le disais à l'origine, la base 60Go n'est pas journalisée.
Elle
> > est surtout utilisée en lecture. Mais ça n'empêche pas que des
> > d'insert assez volumineux sont effectuées couramment , de même que des
bcp.
> > Actuellement, ceux-ci posent problème car deviennent bloquant pour
d'autres
> > écritures mais aussi lectures sur cette base et les autres. Est-ce que
ce
> > genre de config pourrait résoudre ce problème ?
> >
> > Questions complémentaires :
> > si on retient l'option RAID1 (système+log) + RAID5 (data), est-ce que
> > nécessite (ou est-il préférable d'avoir) plusieurs cartes RAID.
> > Et concernant la mémoire cache embarquée sur la ou les cartes,
des
> > préconisations sur sa quantité mini en fonction de la taille ou du
nombre de
> > disques gérés.
> >
> > Cordialement,
> > Sébastien
> >
> > "Med Bouchenafa[MVP]" a écrit dans le
de
> > news:%23fSBcv4%
> > > > Les logs me semblent plus importantes que les data.
> > > Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes
> > > prendre en compte.
> > > Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse
> > > lecture
> > > Pour le log, on doit privilégier l'écriture pour libérer au plus
le
> > > moteur
> > > Pour les données, c'est plutôt la lecture que l'on doit privilégier
> > >
> > > --
> > > Bien cordialement
> > > Med Bouchenafa
> > > TETRASET
> > > 75015 Paris
> > >
> > > "Vuillermet Jacques" wrote in message
> > > news:Oamk9R4#
> > > > Les logs me semblent plus importantes que les data.
> > > > En cas de crash sur le disque data, les data non sauvegardées sont
> > > > entièrement récupérables par full restore + logs, alors que rien
> > permet
> > > > de récupérer des logs non sauvegardés.
> > > >
> > > > Donc, j'aurai mis RAID 5 pour les logs et RAID 1 pour les data.
> > > >
> > > > Jacques.
> > > >
> > > > "Med Bouchenafa[MVP]" a écrit dans le
message
> > de
> > > > news: #JkQV23#
> > > > > Puisque tu évolues vers une nouvelle machine, il faut prévoir
> > idéalement
> > > :
> > > > >
> > > > > 1) Un RAID 1 pour l' OS
> > > > >
> > > > > 2) Un autre RAID 1 pour les log
> > > > > Les IO sur le log sont essentiellement séquentiels.
> > > > > S'il n'y a qu'un seul fichier de log, il serait intéressant
de le
> > > > > placer sur un RAID 1
> > > > > L'avantage s'estompe quelque peu s'il y a plusieurs
> > log.
> > > > > Quoi qu'il en soit, il est toujours intéressant de mettre
log
> > à
> > > > > part.
> > > > >
> > > > > 3) Un RAID 0 pour TempDB
> > > > > Inutile de prévoir de la tolérance de panne pour TempDB.
> > > > > Elle peut se contenter d'un RAID 0 car elle est reconstruite
> > > chaque
> > > > > démarrage de SQL Server
> > > > >
> > > > > 4) Un RAID 5 pour les data
> > > > > --
> > > > > Bien cordialement
> > > > > Med Bouchenafa
> > > > > TETRASET
> > > > > 75015 Paris
> > > > > "Sebastien" wrote in
> > > > > news:O#3w64x#
> > > > > > Bonjour / Bonsoir,
> > > > > > Une question technique concernant les disques
> > > > > > Dans ma boite, nous allons faire évoluer un serveur SQL 2000,
> > > > actuellement
> > > > > > avec des disques en RAID5 (6x32Go) uniquement
> > > > > > Il contient une base de 60Go environ, non journalisée, et
quelques
> > > > autres
> > > > > > bases journalisées mais de 100/200Mo maxi.
> > > > > > Par moment, lorsque certains utilisateurs font de méga
> > > d'insert
> > > > > sur
> > > > > > la base 60Go ou en tempdb, ça fait ramer tout le monde, en
lecture
> > > aussi
> > > > > > bien qu'en écriture. Idem lors de la création d'index
par
> > > > > exemple.
> > > > > > Est-ce que si les journaux de transactions et la tempdb
sur
> > > > > d'autres
> > > > > > disques, par exemple en miroir, ça améliorerait les choses. Ou
> > est-ce
> > > > que
> > > > > > c'est la carte RAID qui pourrait être trop lente (pas assez de
> > mémoire
> > > > > > cache? (32 Mo)) ou les disques qui pourraient être trop lent.
> > > > > >
> > > > > > Merci d'avance
> > > > > > Sébastien
Et le raid 10 alors, c'est pour les chiens ???
(Raid 0 + 1)
A +
Med Bouchenafa[MVP] a écrit:
>>Les logs me semblent plus importantes que les data.
>
> Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
> prendre en compte.
> Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
> lecture
> Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
> moteur
> Pour les données, c'est plutôt la lecture que l'on doit privilégier
>
--
Frédéric BROUARD, MVP Microsoft SQL Server. 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
****************** mailto: ******************
Et le raid 10 alors, c'est pour les chiens ???
(Raid 0 + 1)
A +
Med Bouchenafa[MVP] a écrit:
>>Les logs me semblent plus importantes que les data.
>
> Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
> prendre en compte.
> Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
> lecture
> Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
> moteur
> Pour les données, c'est plutôt la lecture que l'on doit privilégier
>
--
Frédéric BROUARD, MVP Microsoft SQL Server. 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
****************** mailto:brouardf@club-internet.fr ******************
Et le raid 10 alors, c'est pour les chiens ???
(Raid 0 + 1)
A +
Med Bouchenafa[MVP] a écrit:
>>Les logs me semblent plus importantes que les data.
>
> Je suis bien d'accord. Mais il n'y a pas que la tolérance de pannes à
> prendre en compte.
> Un RAID 1 est plus performant en écriture qu'un RAID 5 et l'inverse en
> lecture
> Pour le log, on doit privilégier l'écriture pour libérer au plus vite le
> moteur
> Pour les données, c'est plutôt la lecture que l'on doit privilégier
>
--
Frédéric BROUARD, MVP Microsoft SQL Server. 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
****************** mailto: ******************