Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur SQL 2000 et performances

SQL 2000 et performances

7 réponses
Avatar
Houdini
Bonjour à toutes et à tous,

Contexte: 1 serveur Compaq G3 ML370 avec 2 Go Ram + Raid1 U3Scsi (2*18) +
Raid5 U3Scsi (4*36 Go) - Bi-Pro Xéon 2,4 Ghz. Une vingtaine de petites bases
(les plus grosses font entre 500 Mo et 1,3 Go et ne sont que 4).

Fonctionnement: les utilisateurs s'authentifient à partir d'une application
Intranet (sur un serveur indépendant Redhat Linux + PHP), la base de
l'intranet est stockée sur le serveur BDD. L'authentification est assez
rapide, ce qui l'est moins c'est le temps de chargement de l'application
(côté PHP, c'est assez optimisé). Les flux passent par un connecteur FreeTDS
(côté Linux / PHP).

Une fois l'authentification passée, ils accèdent à une autre application
(transactionnelle)qui fonctionne sur le même serveur de BDD (les utilisateurs
peuvent passer par Citrix, car sites distants). Cette seconde applications
(VB6 + JAVA + SQL) dialogue avec le serveur BDD via un connecteur JDBC natif
SQL Serveur 2000.

Questions:
1)- Je souhaiterais capturer les trames, flux et éventuellement ordres, qui
transitent au travers de ces deux connecteurs (en entrée et en sortie). Le
Générateur de Profils est-il capable de faire ces tâches ? Si oui, quels sont
les paramètres à indiquer ?

2)- Je souhaiterais faire la même chose, mais au niveau de la seconde
application, pour capturer les trames, flux et ordres, lancés par depuis
l'application VB, qui contient des procédures SQL, dans le code VB. Est-ce
possible ? Si oui, comment et avec quels outils ?

3)-Le Générateur de Profils peut fonctionner conjointement avec l'Optimiseur
de requêtes. Je souhaitement capturer les transactions qui prennent beaucoup
trop de temps et ainsi proposer une amélioration du code. Quels sont les
paramètres les plus pertinents à utiliser pour réaliser cette capture ?

4)- Existe-t-il des outils (autre que ceux intégrés à SQL 2000) pour
identifier les problématiques de "tuning" et d'optimisation ?

5)-Dans le code des procédures stockées (et des fonctions définies par
l"utilisateurs), il est toujours fait appel à des curseurs (FETCH), des
jointures (pas forcement nécessaires comme LEFT OUTER JOIN, RIGHT OUTER JOIN).

6)-Que doit-on utiliser, procédures ou fonctions, qui est le plus rapide ?
Sachant que dans tous les cas, le passage de paramètres est utilisé.

7)-Peut-on remplacer les OUTER JOIN par des SELECT IN et des vues ? Cela
augmente-t-il les performances ? Comment fonctionne réellement ces
instructions (dans les cours, ils ne précisent rien) ? Les curseurs sont
employés continuellement, peut-on s'en passer ? Si oui, dans quels cas et
cela joue-t-il dans une problématique de performances ?

Merci d'avoir pris le temps de me lire (même si c'est long) et je vous
remercie d'avance pour vos réponses pertinentes.
Meilleurs voeux pour 2005 et continuez de nous abreuver de toutes ces
merveilleuses techniques.
Houdini
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
bruno reiter [MVP]
inline

br

"Houdini" wrote in message
news:
Bonjour à toutes et à tous,

Contexte: 1 serveur Compaq G3 ML370 avec 2 Go Ram + Raid1 U3Scsi (2*18) +
Raid5 U3Scsi (4*36 Go) - Bi-Pro Xéon 2,4 Ghz. Une vingtaine de petites


bases
(les plus grosses font entre 500 Mo et 1,3 Go et ne sont que 4).

Fonctionnement: les utilisateurs s'authentifient à partir d'une


application
Intranet (sur un serveur indépendant Redhat Linux + PHP), la base de
l'intranet est stockée sur le serveur BDD. L'authentification est assez
rapide, ce qui l'est moins c'est le temps de chargement de l'application
(côté PHP, c'est assez optimisé). Les flux passent par un connecteur


FreeTDS
(côté Linux / PHP).

Une fois l'authentification passée, ils accèdent à une autre application
(transactionnelle)qui fonctionne sur le même serveur de BDD (les


utilisateurs
peuvent passer par Citrix, car sites distants). Cette seconde applications
(VB6 + JAVA + SQL) dialogue avec le serveur BDD via un connecteur JDBC


natif
SQL Serveur 2000.

Questions:
1)- Je souhaiterais capturer les trames, flux et éventuellement ordres,


qui
transitent au travers de ces deux connecteurs (en entrée et en sortie). Le
Générateur de Profils est-il capable de faire ces tâches ? Si oui, quels


sont
les paramètres à indiquer ?



le profiler ne capture pas de trames, pour cela il faut utiliser un sniffer,
par ex network monitor
Par contre il capture toutes les requetes faites au serveur, les filtres
permettent de limiter à des users, des bases, des hotes, des requetes d'une
certaine durée ...

2)- Je souhaiterais faire la même chose, mais au niveau de la seconde
application, pour capturer les trames, flux et ordres, lancés par depuis
l'application VB, qui contient des procédures SQL, dans le code VB. Est-ce
possible ? Si oui, comment et avec quels outils ?



voir 1) , pour des stats plus larges, le moniteur system (perfmon) peut etre
utilisé


3)-Le Générateur de Profils peut fonctionner conjointement avec


l'Optimiseur
de requêtes. Je souhaitement capturer les transactions qui prennent


beaucoup
trop de temps et ainsi proposer une amélioration du code. Quels sont les
paramètres les plus pertinents à utiliser pour réaliser cette capture ?



on peut aussi récupérer le texte des requetes dans le profiler pour les
analyser dans QA

4)- Existe-t-il des outils (autre que ceux intégrés à SQL 2000) pour
identifier les problématiques de "tuning" et d'optimisation ?



Je ne connais pas d'outils externes de tuning (non MS)

5)-Dans le code des procédures stockées (et des fonctions définies par
l"utilisateurs), il est toujours fait appel à des curseurs (FETCH), des
jointures (pas forcement nécessaires comme LEFT OUTER JOIN, RIGHT OUTER


JOIN).

6)-Que doit-on utiliser, procédures ou fonctions, qui est le plus rapide ?
Sachant que dans tous les cas, le passage de paramètres est utilisé.



les fonctions dans la liste de sélection sont souvent pénalisantes, entre
fonction et SP pas de différence de perf mais d'utilisation

7)-Peut-on remplacer les OUTER JOIN par des SELECT IN et des vues ? Cela
augmente-t-il les performances ? Comment fonctionne réellement ces
instructions (dans les cours, ils ne précisent rien) ? Les curseurs sont
employés continuellement, peut-on s'en passer ? Si oui, dans quels cas et
cela joue-t-il dans une problématique de performances ?



le JOIN est plus performant, mais OUTER JOIN est couteux, on ne l'utilise
que quand c'est "absolument" nécessaire
les tables temporaires peuvent être intéressantes
On peut presque toujours se passer de curseur et gagner beaucoup en perf


Merci d'avoir pris le temps de me lire (même si c'est long) et je vous
remercie d'avance pour vos réponses pertinentes.
Meilleurs voeux pour 2005 et continuez de nous abreuver de toutes ces
merveilleuses techniques.
Houdini


Avatar
Houdini
Merci beaucoup pour toutes ces réponses rapides, mais j'ai encore besoin de
votre aide sur les points suivants:

A)-Les curseurs ne sont pas les bienvenus, pourriez-vous me rappeler à quoi
ils servent réellement, car dans les cours MS SQL, il n'est jamais fait
allusion à ce type d'obet ... comment les remplacer ? Auriez-vous un exemple
concret, avec un exemple de code ?

B)-Comment déterminer la famille d'index sur un colonne d'une table ? Je
voudrais savoir si il s'agit d'un index cluster ou non cluster, soit en
passant par une commande DBCC / sp ou par l'Enterprise Manager.

C)-J'ai besoin de déplacer les fichiers journaux de transactions (ldf) de
plusieurs bdd, y d'un disque vers un autre. Quelles sont les méthodes les
plus fiables et les plu s performantes ?

-Détacher toutes les bases, puis déplacer tous les .LDF vers le nouvel
emplacement, puis réattacher)

-Modifier par un ALTER DATABASE l'emplacement des fichiers journaux ?
(dans ce cas un simple Modify file suffirait-il ?)

-Les LDF sytèmes (master, msdb, pubs, tempdb) doivent-ils être déplacés
aussi ?

(Avec un exemple concert de commandes si besoins)

D)-Comment régler la TEMPDB ? Existe-t-il une façon d'optimiser cette foutue
TEMPDB ?
Merci d'avance pour toutes vos réponses
Cordialement,
Houdini

"bruno reiter [MVP]" a écrit :

inline

br

"Houdini" wrote in message
news:
> Bonjour à toutes et à tous,
>
> Contexte: 1 serveur Compaq G3 ML370 avec 2 Go Ram + Raid1 U3Scsi (2*18) +
> Raid5 U3Scsi (4*36 Go) - Bi-Pro Xéon 2,4 Ghz. Une vingtaine de petites
bases
> (les plus grosses font entre 500 Mo et 1,3 Go et ne sont que 4).
>
> Fonctionnement: les utilisateurs s'authentifient à partir d'une
application
> Intranet (sur un serveur indépendant Redhat Linux + PHP), la base de
> l'intranet est stockée sur le serveur BDD. L'authentification est assez
> rapide, ce qui l'est moins c'est le temps de chargement de l'application
> (côté PHP, c'est assez optimisé). Les flux passent par un connecteur
FreeTDS
> (côté Linux / PHP).
>
> Une fois l'authentification passée, ils accèdent à une autre application
> (transactionnelle)qui fonctionne sur le même serveur de BDD (les
utilisateurs
> peuvent passer par Citrix, car sites distants). Cette seconde applications
> (VB6 + JAVA + SQL) dialogue avec le serveur BDD via un connecteur JDBC
natif
> SQL Serveur 2000.
>
> Questions:
> 1)- Je souhaiterais capturer les trames, flux et éventuellement ordres,
qui
> transitent au travers de ces deux connecteurs (en entrée et en sortie). Le
> Générateur de Profils est-il capable de faire ces tâches ? Si oui, quels
sont
> les paramètres à indiquer ?
>
le profiler ne capture pas de trames, pour cela il faut utiliser un sniffer,
par ex network monitor
Par contre il capture toutes les requetes faites au serveur, les filtres
permettent de limiter à des users, des bases, des hotes, des requetes d'une
certaine durée ...

> 2)- Je souhaiterais faire la même chose, mais au niveau de la seconde
> application, pour capturer les trames, flux et ordres, lancés par depuis
> l'application VB, qui contient des procédures SQL, dans le code VB. Est-ce
> possible ? Si oui, comment et avec quels outils ?
>
voir 1) , pour des stats plus larges, le moniteur system (perfmon) peut etre
utilisé


> 3)-Le Générateur de Profils peut fonctionner conjointement avec
l'Optimiseur
> de requêtes. Je souhaitement capturer les transactions qui prennent
beaucoup
> trop de temps et ainsi proposer une amélioration du code. Quels sont les
> paramètres les plus pertinents à utiliser pour réaliser cette capture ?
>
on peut aussi récupérer le texte des requetes dans le profiler pour les
analyser dans QA

> 4)- Existe-t-il des outils (autre que ceux intégrés à SQL 2000) pour
> identifier les problématiques de "tuning" et d'optimisation ?
>
Je ne connais pas d'outils externes de tuning (non MS)

> 5)-Dans le code des procédures stockées (et des fonctions définies par
> l"utilisateurs), il est toujours fait appel à des curseurs (FETCH), des
> jointures (pas forcement nécessaires comme LEFT OUTER JOIN, RIGHT OUTER
JOIN).
>
> 6)-Que doit-on utiliser, procédures ou fonctions, qui est le plus rapide ?
> Sachant que dans tous les cas, le passage de paramètres est utilisé.
>
les fonctions dans la liste de sélection sont souvent pénalisantes, entre
fonction et SP pas de différence de perf mais d'utilisation

> 7)-Peut-on remplacer les OUTER JOIN par des SELECT IN et des vues ? Cela
> augmente-t-il les performances ? Comment fonctionne réellement ces
> instructions (dans les cours, ils ne précisent rien) ? Les curseurs sont
> employés continuellement, peut-on s'en passer ? Si oui, dans quels cas et
> cela joue-t-il dans une problématique de performances ?
>
le JOIN est plus performant, mais OUTER JOIN est couteux, on ne l'utilise
que quand c'est "absolument" nécessaire
les tables temporaires peuvent être intéressantes
On peut presque toujours se passer de curseur et gagner beaucoup en perf


> Merci d'avoir pris le temps de me lire (même si c'est long) et je vous
> remercie d'avance pour vos réponses pertinentes.
> Meilleurs voeux pour 2005 et continuez de nous abreuver de toutes ces
> merveilleuses techniques.
> Houdini





Avatar
self
"Houdini" a écrit dans le message de
news:
Merci beaucoup pour toutes ces réponses rapides, mais j'ai encore besoin


de
votre aide sur les points suivants:



self: tout d'abord, merci pour ta réponse sur le post 'retour d'expérience
DBA ..
'

A)-Les curseurs ne sont pas les bienvenus, pourriez-vous me rappeler à


quoi
ils servent réellement, car dans les cours MS SQL, il n'est jamais fait
allusion à ce type d'obet ... comment les remplacer ? Auriez-vous un


exemple
concret, avec un exemple de code ?



On peut s'en passer. Je retrouve l'astuce et je te (vous) tiens au courant.

B)-Comment déterminer la famille d'index sur un colonne d'une table ? Je
voudrais savoir si il s'agit d'un index cluster ou non cluster, soit en
passant par une commande DBCC / sp ou par l'Enterprise Manager.



sp_helpindex 'nom_table' ou sp_help 'nom_table'
par EM, clique droit sur une table, toutes les tâches -> gérer les index, il
y a une colonne "ordonné"



C)-J'ai besoin de déplacer les fichiers journaux de transactions (ldf) de
plusieurs bdd, y d'un disque vers un autre. Quelles sont les méthodes les
plus fiables et les plu s performantes ?

-Détacher toutes les bases, puis déplacer tous les .LDF vers le nouvel
emplacement, puis réattacher)



self: ca me parait la plus aisée et fiable, soit par requetes, soit par EM
par sécurité, faire un dbcc checkdb avant.

-Modifier par un ALTER DATABASE l'emplacement des fichiers journaux ?
(dans ce cas un simple Modify file suffirait-il ?)

-Les LDF sytèmes (master, msdb, pubs, tempdb) doivent-ils être déplacés
aussi ?



self: pas nécessaire, sauf tempdb, voir en dessous

(Avec un exemple concert de commandes si besoins)

D)-Comment régler la TEMPDB ? Existe-t-il une façon d'optimiser cette


foutue
TEMPDB ?



self; idéalement, il faut la mettre sur un disque dédié car très gourmand en
I/O
Il est conseillé de lui mettre une taille fixe (assez large), éviter
l'accroissement auto+réduction auto.

la tempdb n'est pas très optimisable, c'est plutôt ce qu'on y insére qu'il
faut optimiser (voir indexer)

Et voir si on peut s'en passer:
- les variables tables permettent d'éviter les tables temporaires, c'est
sensé être plus performant. A tester en fonction du besoin.


pour la déplacer, voici un "How-to"

Moving the tempdb database
--------------------------

You can move tempdb files by using the ALTER DATABASE statement.

1. Determine the logical file names for the tempdb database by using
sp_helpfile
as follows:

use tempdb
go
sp_helpfile
go

The logical name for each file is contained in the name column. This example
uses
the default file names of tempdev and templog.

2. Use the ALTER DATABASE statement, specifying the logical file name as
follows:

use master
go
Alter database tempdb modify file (name = tempdev, filename 'E:Mssql8Datatempdb.mdf')
go
Alter database tempdb modify file (name = templog, filename 'E:Mssql8Datatemplog.ldf')
go

You should receive the following messages confirming the change:

File 'tempdev' modified in sysaltfiles. Delete old file after restarting
SQL
Server.

File 'templog' modified in sysaltfiles. Delete old file after restarting
SQL
Server.

3. Using sp_helpfile in tempdb will not confirm these changes until you
restart
SQL Server.

4. Stop and restart SQL Server.

5. Delete the old tempdb.mdf and templog.ldf files.
Avatar
Houdini
Bonsoir,

Merci d'avoir répondu si rapidement à mes questions et j'attends avec
impatience les astuces pour éviter les curseurs.

Pour ce qui concerne le "retour d'expérience DBA", c'est avec plaisir que je
t'ai renseigné (je prends la permission de vous tutoyer, tu peux faire de
même, je ne suis ni ministre, ni président). Etant sur Rennes et les
départements limitrophes, c'est plus facile.

Merci d'avance...
Houdini

"self" a écrit :


"Houdini" a écrit dans le message de
news:
> Merci beaucoup pour toutes ces réponses rapides, mais j'ai encore besoin
de
> votre aide sur les points suivants:

self: tout d'abord, merci pour ta réponse sur le post 'retour d'expérience
DBA ..
'
>
> A)-Les curseurs ne sont pas les bienvenus, pourriez-vous me rappeler à
quoi
> ils servent réellement, car dans les cours MS SQL, il n'est jamais fait
> allusion à ce type d'obet ... comment les remplacer ? Auriez-vous un
exemple
> concret, avec un exemple de code ?

On peut s'en passer. Je retrouve l'astuce et je te (vous) tiens au courant.
>
> B)-Comment déterminer la famille d'index sur un colonne d'une table ? Je
> voudrais savoir si il s'agit d'un index cluster ou non cluster, soit en
> passant par une commande DBCC / sp ou par l'Enterprise Manager.

sp_helpindex 'nom_table' ou sp_help 'nom_table'
par EM, clique droit sur une table, toutes les tâches -> gérer les index, il
y a une colonne "ordonné"


>
> C)-J'ai besoin de déplacer les fichiers journaux de transactions (ldf) de
> plusieurs bdd, y d'un disque vers un autre. Quelles sont les méthodes les
> plus fiables et les plu s performantes ?
>
> -Détacher toutes les bases, puis déplacer tous les .LDF vers le nouvel
> emplacement, puis réattacher)
>
self: ca me parait la plus aisée et fiable, soit par requetes, soit par EM
par sécurité, faire un dbcc checkdb avant.

> -Modifier par un ALTER DATABASE l'emplacement des fichiers journaux ?
> (dans ce cas un simple Modify file suffirait-il ?)
>
> -Les LDF sytèmes (master, msdb, pubs, tempdb) doivent-ils être déplacés
> aussi ?
>
self: pas nécessaire, sauf tempdb, voir en dessous

> (Avec un exemple concert de commandes si besoins)
>
> D)-Comment régler la TEMPDB ? Existe-t-il une façon d'optimiser cette
foutue
> TEMPDB ?

self; idéalement, il faut la mettre sur un disque dédié car très gourmand en
I/O
Il est conseillé de lui mettre une taille fixe (assez large), éviter
l'accroissement auto+réduction auto.

la tempdb n'est pas très optimisable, c'est plutôt ce qu'on y insére qu'il
faut optimiser (voir indexer)

Et voir si on peut s'en passer:
- les variables tables permettent d'éviter les tables temporaires, c'est
sensé être plus performant. A tester en fonction du besoin.


pour la déplacer, voici un "How-to"

Moving the tempdb database
--------------------------

You can move tempdb files by using the ALTER DATABASE statement.

1. Determine the logical file names for the tempdb database by using
sp_helpfile
as follows:

use tempdb
go
sp_helpfile
go

The logical name for each file is contained in the name column. This example
uses
the default file names of tempdev and templog.

2. Use the ALTER DATABASE statement, specifying the logical file name as
follows:

use master
go
Alter database tempdb modify file (name = tempdev, filename > 'E:Mssql8Datatempdb.mdf')
go
Alter database tempdb modify file (name = templog, filename > 'E:Mssql8Datatemplog.ldf')
go

You should receive the following messages confirming the change:

File 'tempdev' modified in sysaltfiles. Delete old file after restarting
SQL
Server.

File 'templog' modified in sysaltfiles. Delete old file after restarting
SQL
Server.

3. Using sp_helpfile in tempdb will not confirm these changes until you
restart
SQL Server.

4. Stop and restart SQL Server.

5. Delete the old tempdb.mdf and templog.ldf files.








Avatar
Philippe T [MS]
Bonjour,

Pour éviter les curseurs, il faut au maximum utiliser des opérations
ensemblistes. Un curseur permet de se déplacer d'un enregistrement à un
autre afin de traiter les lignes renvoyées par une requête les unes après
les autres.

Exemple:

-- Création d'une table
DECLARE @MyTable TABLE(TABLE_CODE nvarchar(100), TABLE_VALUE int)
INSERT INTO @MyTable (TABLE_CODE, TABLE_VALUE) VALUES('A', 1)
INSERT INTO @MyTable (TABLE_CODE, TABLE_VALUE) VALUES('B', 2)
INSERT INTO @MyTable (TABLE_CODE, TABLE_VALUE) VALUES('C', 3)

Pour incrémenter TABLE_VALUE de 1 pour chaque enregistrement, il est
préférable de faire :

UPDATE @MyTable SET TABLE_VALUE = TABLE_VALUE + 1

que de faire:

DECLARE @Cur_MyCode nvarchar(100)
DECLARE Cursor_MyTable CURSOR FAST_FORWARD FOR
SELECT TABLE_CODE FROM @MyTable

OPEN Cursor_MyTable
FETCH NEXT FROM Cursor_MyTable INTO @Cur_MyCode

WHILE (@@fetch_status = 0)
BEGIN
UPDATE @MyTable SET TABLE_VALUE = TABLE_VALUE + 1 WHERE TABLE_CODE @Cur_MyCode
FETCH NEXT FROM Cursor_MyTable INTO @Cur_MyCode
END
CLOSE Cursor_MyTable
DEALLOCATE Cursor_MyTable

Bon, là l'exemple est trop simple mais c'est l'idée. Travailler de façon
ensembliste quand c'est possible !!!


Pour effectuer correctement une optimisation, les étapes à franchir sont :

1. Analyse du serveur Windows hébergeant la base de données. Souvent une
mauvaise installation de SQL Server nuit aux performances
2. Analyse de l'installation de SQL Server. Y a t il des paramètres
particuliers / Collation de la base / ...
3. Analyse de la localisation de la base de données. Disques hébergeant les
données et les logs, taille de la TempDB, pas de croissance des fichiers,
...
4. Analyse du contenu de la base. Capture au profiler de traces
représentatives / Analyse des plan de maintenance des procédures couteuses /
...

Bon courage.

Phil.
________________________________________________________
Philippe TROTIN http://blogs.msdn.com/ptrotin
Microsoft Services France http://www.microsoft.com/france

"Houdini" wrote in message
news:
Bonsoir,

Merci d'avoir répondu si rapidement à mes questions et j'attends avec
impatience les astuces pour éviter les curseurs.

Pour ce qui concerne le "retour d'expérience DBA", c'est avec plaisir que


je
t'ai renseigné (je prends la permission de vous tutoyer, tu peux faire de
même, je ne suis ni ministre, ni président). Etant sur Rennes et les
départements limitrophes, c'est plus facile.

Merci d'avance...
Houdini

"self" a écrit :

>
> "Houdini" a écrit dans le message de
> news:
> > Merci beaucoup pour toutes ces réponses rapides, mais j'ai encore


besoin
> de
> > votre aide sur les points suivants:
>
> self: tout d'abord, merci pour ta réponse sur le post 'retour


d'expérience
> DBA ..
> '
> >
> > A)-Les curseurs ne sont pas les bienvenus, pourriez-vous me rappeler à
> quoi
> > ils servent réellement, car dans les cours MS SQL, il n'est jamais


fait
> > allusion à ce type d'obet ... comment les remplacer ? Auriez-vous un
> exemple
> > concret, avec un exemple de code ?
>
> On peut s'en passer. Je retrouve l'astuce et je te (vous) tiens au


courant.
> >
> > B)-Comment déterminer la famille d'index sur un colonne d'une table ?


Je
> > voudrais savoir si il s'agit d'un index cluster ou non cluster, soit


en
> > passant par une commande DBCC / sp ou par l'Enterprise Manager.
>
> sp_helpindex 'nom_table' ou sp_help 'nom_table'
> par EM, clique droit sur une table, toutes les tâches -> gérer les


index, il
> y a une colonne "ordonné"
>
>
> >
> > C)-J'ai besoin de déplacer les fichiers journaux de transactions (ldf)


de
> > plusieurs bdd, y d'un disque vers un autre. Quelles sont les méthodes


les
> > plus fiables et les plu s performantes ?
> >
> > -Détacher toutes les bases, puis déplacer tous les .LDF vers le nouvel
> > emplacement, puis réattacher)
> >
> self: ca me parait la plus aisée et fiable, soit par requetes, soit par


EM
> par sécurité, faire un dbcc checkdb avant.
>
> > -Modifier par un ALTER DATABASE l'emplacement des fichiers journaux ?
> > (dans ce cas un simple Modify file suffirait-il ?)
> >
> > -Les LDF sytèmes (master, msdb, pubs, tempdb) doivent-ils être


déplacés
> > aussi ?
> >
> self: pas nécessaire, sauf tempdb, voir en dessous
>
> > (Avec un exemple concert de commandes si besoins)
> >
> > D)-Comment régler la TEMPDB ? Existe-t-il une façon d'optimiser cette
> foutue
> > TEMPDB ?
>
> self; idéalement, il faut la mettre sur un disque dédié car très


gourmand en
> I/O
> Il est conseillé de lui mettre une taille fixe (assez large), éviter
> l'accroissement auto+réduction auto.
>
> la tempdb n'est pas très optimisable, c'est plutôt ce qu'on y insére


qu'il
> faut optimiser (voir indexer)
>
> Et voir si on peut s'en passer:
> - les variables tables permettent d'éviter les tables temporaires, c'est
> sensé être plus performant. A tester en fonction du besoin.
>
>
> pour la déplacer, voici un "How-to"
>
> Moving the tempdb database
> --------------------------
>
> You can move tempdb files by using the ALTER DATABASE statement.
>
> 1. Determine the logical file names for the tempdb database by using
> sp_helpfile
> as follows:
>
> use tempdb
> go
> sp_helpfile
> go
>
> The logical name for each file is contained in the name column. This


example
> uses
> the default file names of tempdev and templog.
>
> 2. Use the ALTER DATABASE statement, specifying the logical file name as
> follows:
>
> use master
> go
> Alter database tempdb modify file (name = tempdev, filename > > 'E:Mssql8Datatempdb.mdf')
> go
> Alter database tempdb modify file (name = templog, filename > > 'E:Mssql8Datatemplog.ldf')
> go
>
> You should receive the following messages confirming the change:
>
> File 'tempdev' modified in sysaltfiles. Delete old file after


restarting
> SQL
> Server.
>
> File 'templog' modified in sysaltfiles. Delete old file after


restarting
> SQL
> Server.
>
> 3. Using sp_helpfile in tempdb will not confirm these changes until you
> restart
> SQL Server.
>
> 4. Stop and restart SQL Server.
>
> 5. Delete the old tempdb.mdf and templog.ldf files.
>
>
>
>
>
>


Avatar
Houdini
Bonjour,

Merci pour toutes ces réponses, j'ai déjà préconisé et valider les parties
hard et soft. Au niveau de la TEMPDB, quelle taille faudrait-il mettre ?
(assez importante n'est pas une mesure) ?

Existe-t-il un moyen de purger régulièrement le contenu de la TEMPDB, de
façon à optimiser les I/O ?

Au niveau des connecteurs de bases de données, quels mesures pourrais-je
faire pour savoir ce qui se passe en entrée et/ou en sortie d'une application
?

Merci d'avance.
Houdini
"Philippe T [MS]" a écrit :

Bonjour,

Pour éviter les curseurs, il faut au maximum utiliser des opérations
ensemblistes. Un curseur permet de se déplacer d'un enregistrement à un
autre afin de traiter les lignes renvoyées par une requête les unes après
les autres.

Exemple:

-- Création d'une table
DECLARE @MyTable TABLE(TABLE_CODE nvarchar(100), TABLE_VALUE int)
INSERT INTO @MyTable (TABLE_CODE, TABLE_VALUE) VALUES('A', 1)
INSERT INTO @MyTable (TABLE_CODE, TABLE_VALUE) VALUES('B', 2)
INSERT INTO @MyTable (TABLE_CODE, TABLE_VALUE) VALUES('C', 3)

Pour incrémenter TABLE_VALUE de 1 pour chaque enregistrement, il est
préférable de faire :

UPDATE @MyTable SET TABLE_VALUE = TABLE_VALUE + 1

que de faire:

DECLARE @Cur_MyCode nvarchar(100)
DECLARE Cursor_MyTable CURSOR FAST_FORWARD FOR
SELECT TABLE_CODE FROM @MyTable

OPEN Cursor_MyTable
FETCH NEXT FROM Cursor_MyTable INTO @Cur_MyCode

WHILE (@@fetch_status = 0)
BEGIN
UPDATE @MyTable SET TABLE_VALUE = TABLE_VALUE + 1 WHERE TABLE_CODE > @Cur_MyCode
FETCH NEXT FROM Cursor_MyTable INTO @Cur_MyCode
END
CLOSE Cursor_MyTable
DEALLOCATE Cursor_MyTable

Bon, là l'exemple est trop simple mais c'est l'idée. Travailler de façon
ensembliste quand c'est possible !!!


Pour effectuer correctement une optimisation, les étapes à franchir sont :

1. Analyse du serveur Windows hébergeant la base de données. Souvent une
mauvaise installation de SQL Server nuit aux performances
2. Analyse de l'installation de SQL Server. Y a t il des paramètres
particuliers / Collation de la base / ...
3. Analyse de la localisation de la base de données. Disques hébergeant les
données et les logs, taille de la TempDB, pas de croissance des fichiers,
....
4. Analyse du contenu de la base. Capture au profiler de traces
représentatives / Analyse des plan de maintenance des procédures couteuses /
....

Bon courage.

Phil.
________________________________________________________
Philippe TROTIN http://blogs.msdn.com/ptrotin
Microsoft Services France http://www.microsoft.com/france

"Houdini" wrote in message
news:
> Bonsoir,
>
> Merci d'avoir répondu si rapidement à mes questions et j'attends avec
> impatience les astuces pour éviter les curseurs.
>
> Pour ce qui concerne le "retour d'expérience DBA", c'est avec plaisir que
je
> t'ai renseigné (je prends la permission de vous tutoyer, tu peux faire de
> même, je ne suis ni ministre, ni président). Etant sur Rennes et les
> départements limitrophes, c'est plus facile.
>
> Merci d'avance...
> Houdini
>
> "self" a écrit :
>
> >
> > "Houdini" a écrit dans le message de
> > news:
> > > Merci beaucoup pour toutes ces réponses rapides, mais j'ai encore
besoin
> > de
> > > votre aide sur les points suivants:
> >
> > self: tout d'abord, merci pour ta réponse sur le post 'retour
d'expérience
> > DBA ..
> > '
> > >
> > > A)-Les curseurs ne sont pas les bienvenus, pourriez-vous me rappeler à
> > quoi
> > > ils servent réellement, car dans les cours MS SQL, il n'est jamais
fait
> > > allusion à ce type d'obet ... comment les remplacer ? Auriez-vous un
> > exemple
> > > concret, avec un exemple de code ?
> >
> > On peut s'en passer. Je retrouve l'astuce et je te (vous) tiens au
courant.
> > >
> > > B)-Comment déterminer la famille d'index sur un colonne d'une table ?
Je
> > > voudrais savoir si il s'agit d'un index cluster ou non cluster, soit
en
> > > passant par une commande DBCC / sp ou par l'Enterprise Manager.
> >
> > sp_helpindex 'nom_table' ou sp_help 'nom_table'
> > par EM, clique droit sur une table, toutes les tâches -> gérer les
index, il
> > y a une colonne "ordonné"
> >
> >
> > >
> > > C)-J'ai besoin de déplacer les fichiers journaux de transactions (ldf)
de
> > > plusieurs bdd, y d'un disque vers un autre. Quelles sont les méthodes
les
> > > plus fiables et les plu s performantes ?
> > >
> > > -Détacher toutes les bases, puis déplacer tous les .LDF vers le nouvel
> > > emplacement, puis réattacher)
> > >
> > self: ca me parait la plus aisée et fiable, soit par requetes, soit par
EM
> > par sécurité, faire un dbcc checkdb avant.
> >
> > > -Modifier par un ALTER DATABASE l'emplacement des fichiers journaux ?
> > > (dans ce cas un simple Modify file suffirait-il ?)
> > >
> > > -Les LDF sytèmes (master, msdb, pubs, tempdb) doivent-ils être
déplacés
> > > aussi ?
> > >
> > self: pas nécessaire, sauf tempdb, voir en dessous
> >
> > > (Avec un exemple concert de commandes si besoins)
> > >
> > > D)-Comment régler la TEMPDB ? Existe-t-il une façon d'optimiser cette
> > foutue
> > > TEMPDB ?
> >
> > self; idéalement, il faut la mettre sur un disque dédié car très
gourmand en
> > I/O
> > Il est conseillé de lui mettre une taille fixe (assez large), éviter
> > l'accroissement auto+réduction auto.
> >
> > la tempdb n'est pas très optimisable, c'est plutôt ce qu'on y insére
qu'il
> > faut optimiser (voir indexer)
> >
> > Et voir si on peut s'en passer:
> > - les variables tables permettent d'éviter les tables temporaires, c'est
> > sensé être plus performant. A tester en fonction du besoin.
> >
> >
> > pour la déplacer, voici un "How-to"
> >
> > Moving the tempdb database
> > --------------------------
> >
> > You can move tempdb files by using the ALTER DATABASE statement.
> >
> > 1. Determine the logical file names for the tempdb database by using
> > sp_helpfile
> > as follows:
> >
> > use tempdb
> > go
> > sp_helpfile
> > go
> >
> > The logical name for each file is contained in the name column. This
example
> > uses
> > the default file names of tempdev and templog.
> >
> > 2. Use the ALTER DATABASE statement, specifying the logical file name as
> > follows:
> >
> > use master
> > go
> > Alter database tempdb modify file (name = tempdev, filename > > > 'E:Mssql8Datatempdb.mdf')
> > go
> > Alter database tempdb modify file (name = templog, filename > > > 'E:Mssql8Datatemplog.ldf')
> > go
> >
> > You should receive the following messages confirming the change:
> >
> > File 'tempdev' modified in sysaltfiles. Delete old file after
restarting
> > SQL
> > Server.
> >
> > File 'templog' modified in sysaltfiles. Delete old file after
restarting
> > SQL
> > Server.
> >
> > 3. Using sp_helpfile in tempdb will not confirm these changes until you
> > restart
> > SQL Server.
> >
> > 4. Stop and restart SQL Server.
> >
> > 5. Delete the old tempdb.mdf and templog.ldf files.
> >
> >
> >
> >
> >
> >





Avatar
Fred BROUARD
Outils d'audit externes :

TList (dans le CD Windows Support Tools) permet de voir les processus et les
modules afférents;

Pviewer (dans le CD Windows Support Tools) visualise des informations sur les
processus et les threads et les administre;

Pview (Plateforme SDK) — même fonction que Pviewer;

WinDbg le débogueur (Windows ou téléchargement depuis le site de Microsoft) qui
permet de suivre ce que fait un programme et en particulier ce qui se passe à
l'intérieur de SQL Server.

PssDiag analyse de fichiers de log et de données (site Microsoft)

sp_blocker_pss80 procédure stockée dont le code est fournit par Microsoft pour
analyser les connexions et les ressources associées.


Houdini a écrit:
Bonjour,

Merci pour toutes ces réponses, j'ai déjà préconisé et valider les parties
hard et soft. Au niveau de la TEMPDB, quelle taille faudrait-il mettre ?
(assez importante n'est pas une mesure) ?



Tout dépends de la taille des données manipulées dans les tables temporaires et
les sous requêtes table.
J'aurais tendance à dire : taille max déjà atteinte * 2.5 et à surveiller de
manière administrative à échéances.


Existe-t-il un moyen de purger régulièrement le contenu de la TEMPDB, de
façon à optimiser les I/O ?

Au niveau des connecteurs de bases de données, quels mesures pourrais-je
faire pour savoir ce qui se passe en entrée et/ou en sortie d'une application
?

Merci d'avance.
Houdini



A +

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************


"Philippe T [MS]" a écrit :


Bonjour,

Pour éviter les curseurs, il faut au maximum utiliser des opérations
ensemblistes. Un curseur permet de se déplacer d'un enregistrement à un
autre afin de traiter les lignes renvoyées par une requête les unes après
les autres.

Exemple:

-- Création d'une table
DECLARE @MyTable TABLE(TABLE_CODE nvarchar(100), TABLE_VALUE int)
INSERT INTO @MyTable (TABLE_CODE, TABLE_VALUE) VALUES('A', 1)
INSERT INTO @MyTable (TABLE_CODE, TABLE_VALUE) VALUES('B', 2)
INSERT INTO @MyTable (TABLE_CODE, TABLE_VALUE) VALUES('C', 3)

Pour incrémenter TABLE_VALUE de 1 pour chaque enregistrement, il est
préférable de faire :

UPDATE @MyTable SET TABLE_VALUE = TABLE_VALUE + 1

que de faire:

DECLARE @Cur_MyCode nvarchar(100)
DECLARE Cursor_MyTable CURSOR FAST_FORWARD FOR
SELECT TABLE_CODE FROM @MyTable

OPEN Cursor_MyTable
FETCH NEXT FROM Cursor_MyTable INTO @Cur_MyCode

WHILE (@@fetch_status = 0)
BEGIN
UPDATE @MyTable SET TABLE_VALUE = TABLE_VALUE + 1 WHERE TABLE_CODE >>@Cur_MyCode
FETCH NEXT FROM Cursor_MyTable INTO @Cur_MyCode
END
CLOSE Cursor_MyTable
DEALLOCATE Cursor_MyTable

Bon, là l'exemple est trop simple mais c'est l'idée. Travailler de façon
ensembliste quand c'est possible !!!


Pour effectuer correctement une optimisation, les étapes à franchir sont :

1. Analyse du serveur Windows hébergeant la base de données. Souvent une
mauvaise installation de SQL Server nuit aux performances
2. Analyse de l'installation de SQL Server. Y a t il des paramètres
particuliers / Collation de la base / ...
3. Analyse de la localisation de la base de données. Disques hébergeant les
données et les logs, taille de la TempDB, pas de croissance des fichiers,
....
4. Analyse du contenu de la base. Capture au profiler de traces
représentatives / Analyse des plan de maintenance des procédures couteuses /
....

Bon courage.

Phil.
________________________________________________________
Philippe TROTIN http://blogs.msdn.com/ptrotin
Microsoft Services France http://www.microsoft.com/france

"Houdini" wrote in message
news:

Bonsoir,

Merci d'avoir répondu si rapidement à mes questions et j'attends avec
impatience les astuces pour éviter les curseurs.

Pour ce qui concerne le "retour d'expérience DBA", c'est avec plaisir que



je

t'ai renseigné (je prends la permission de vous tutoyer, tu peux faire de
même, je ne suis ni ministre, ni président). Etant sur Rennes et les
départements limitrophes, c'est plus facile.

Merci d'avance...
Houdini

"self" a écrit :


"Houdini" a écrit dans le message de
news:

Merci beaucoup pour toutes ces réponses rapides, mais j'ai encore







besoin

de

votre aide sur les points suivants:



self: tout d'abord, merci pour ta réponse sur le post 'retour





d'expérience

DBA ..
'

A)-Les curseurs ne sont pas les bienvenus, pourriez-vous me rappeler à



quoi

ils servent réellement, car dans les cours MS SQL, il n'est jamais







fait

allusion à ce type d'obet ... comment les remplacer ? Auriez-vous un



exemple

concret, avec un exemple de code ?



On peut s'en passer. Je retrouve l'astuce et je te (vous) tiens au





courant.

B)-Comment déterminer la famille d'index sur un colonne d'une table ?







Je

voudrais savoir si il s'agit d'un index cluster ou non cluster, soit







en

passant par une commande DBCC / sp ou par l'Enterprise Manager.



sp_helpindex 'nom_table' ou sp_help 'nom_table'
par EM, clique droit sur une table, toutes les tâches -> gérer les





index, il

y a une colonne "ordonné"



C)-J'ai besoin de déplacer les fichiers journaux de transactions (ldf)







de

plusieurs bdd, y d'un disque vers un autre. Quelles sont les méthodes







les

plus fiables et les plu s performantes ?

-Détacher toutes les bases, puis déplacer tous les .LDF vers le nouvel
emplacement, puis réattacher)




self: ca me parait la plus aisée et fiable, soit par requetes, soit par





EM

par sécurité, faire un dbcc checkdb avant.


-Modifier par un ALTER DATABASE l'emplacement des fichiers journaux ?
(dans ce cas un simple Modify file suffirait-il ?)

-Les LDF sytèmes (master, msdb, pubs, tempdb) doivent-ils être







déplacés

aussi ?




self: pas nécessaire, sauf tempdb, voir en dessous


(Avec un exemple concert de commandes si besoins)

D)-Comment régler la TEMPDB ? Existe-t-il une façon d'optimiser cette



foutue

TEMPDB ?



self; idéalement, il faut la mettre sur un disque dédié car très





gourmand en

I/O
Il est conseillé de lui mettre une taille fixe (assez large), éviter
l'accroissement auto+réduction auto.

la tempdb n'est pas très optimisable, c'est plutôt ce qu'on y insére





qu'il

faut optimiser (voir indexer)

Et voir si on peut s'en passer:
- les variables tables permettent d'éviter les tables temporaires, c'est
sensé être plus performant. A tester en fonction du besoin.


pour la déplacer, voici un "How-to"

Moving the tempdb database
--------------------------

You can move tempdb files by using the ALTER DATABASE statement.

1. Determine the logical file names for the tempdb database by using
sp_helpfile
as follows:

use tempdb
go
sp_helpfile
go

The logical name for each file is contained in the name column. This





example

uses
the default file names of tempdev and templog.

2. Use the ALTER DATABASE statement, specifying the logical file name as
follows:

use master
go
Alter database tempdb modify file (name = tempdev, filename >>>>'E:Mssql8Datatempdb.mdf')
go
Alter database tempdb modify file (name = templog, filename >>>>'E:Mssql8Datatemplog.ldf')
go

You should receive the following messages confirming the change:

File 'tempdev' modified in sysaltfiles. Delete old file after





restarting

SQL
Server.

File 'templog' modified in sysaltfiles. Delete old file after





restarting

SQL
Server.

3. Using sp_helpfile in tempdb will not confirm these changes until you
restart
SQL Server.

4. Stop and restart SQL Server.

5. Delete the old tempdb.mdf and templog.ldf files.


















--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************