J'ai un souci concernant les processus actifs et les Verrous sur ma base en
production...
Je développe une application en servlets Java qui effectue des requêtes sur
la base SQLServer par un utilisateur unique.
Une cinquantaine de personnes utilisent quotidiennement cette appli (et
cette base, donc)
mais ils ne travaillent pas en permanence ;-) et surtout pas la nuit !
Or je trouve de nombreux processus actifs qui datent de la veille (ou
pire...),
un nombre important de spid (numérotés de 51 à 196) dans les verrous...
(tous type DB mode S)
et mes sauvegardes de journal de transactions enflent...
Je ne suis guère compétent en DBAdministration, vous l'aurez compris...
1. Pouvez-vous me confirmer que ces problèmes sont liés (troncature du
journal impossible ?)
2. Comment remédier à ce problème ? comment flinguer les processus anciens ?
comment éliminer les verrous et lesquels ?
3. Quelle pourrait être la cause de cette persistence des transactions ?
> Ne serait ce pas les suavegardes qui ne s'effectuent pas ? (cf le journal des évènements)
Patrice
Les sauvegardes DB et LOG s'effectuent correctement. Mon souci tient au fait qu'une sauvegarde du Journal des transactions occupe 200 à 300 Ko à 8h et 1,7 Go à 12h !...
Je vais modifier la stratégie des sauvegardes pour ne pas accumuler des sauvegardes LOG éloignées des sauvegardes DB... et observer.
Merci de votre aide.
> Ne serait ce pas les suavegardes qui ne s'effectuent pas ? (cf le journal
des évènements)
Patrice
Les sauvegardes DB et LOG s'effectuent correctement.
Mon souci tient au fait qu'une sauvegarde du Journal des transactions occupe
200 à 300 Ko à 8h et 1,7 Go à 12h !...
Je vais modifier la stratégie des sauvegardes pour ne pas accumuler des
sauvegardes LOG éloignées des sauvegardes DB... et observer.
> Ne serait ce pas les suavegardes qui ne s'effectuent pas ? (cf le journal des évènements)
Patrice
Les sauvegardes DB et LOG s'effectuent correctement. Mon souci tient au fait qu'une sauvegarde du Journal des transactions occupe 200 à 300 Ko à 8h et 1,7 Go à 12h !...
Je vais modifier la stratégie des sauvegardes pour ne pas accumuler des sauvegardes LOG éloignées des sauvegardes DB... et observer.
Merci de votre aide.
Jean-Yves FREMONT
> Ne serait ce pas les suavegardes qui ne s'effectuent pas ? (cf le journal des évènements)
Patrice
Les sauvegardes DB et LOG s'effectuent correctement. Mon souci tient au fait qu'une sauvegarde du Journal des transactions occupe 200 à 300 Ko à 8h et 1,7 Go à 12h !...
Je vais modifier la stratégie des sauvegardes pour ne pas accumuler des sauvegardes LOG éloignées des sauvegardes DB... et observer.
Merci de votre aide.
> Ne serait ce pas les suavegardes qui ne s'effectuent pas ? (cf le journal
des évènements)
Patrice
Les sauvegardes DB et LOG s'effectuent correctement.
Mon souci tient au fait qu'une sauvegarde du Journal des transactions occupe
200 à 300 Ko à 8h et 1,7 Go à 12h !...
Je vais modifier la stratégie des sauvegardes pour ne pas accumuler des
sauvegardes LOG éloignées des sauvegardes DB... et observer.
> Ne serait ce pas les suavegardes qui ne s'effectuent pas ? (cf le journal des évènements)
Patrice
Les sauvegardes DB et LOG s'effectuent correctement. Mon souci tient au fait qu'une sauvegarde du Journal des transactions occupe 200 à 300 Ko à 8h et 1,7 Go à 12h !...
Je vais modifier la stratégie des sauvegardes pour ne pas accumuler des sauvegardes LOG éloignées des sauvegardes DB... et observer.
Merci de votre aide.
Jean-Yves FREMONT
> Je pencherais assez pour un probleme du MiddleWare qui fait du pooling de connection.
Avec dans l'application l'absence de Connection.close
Laurent.
Cela me parait être une piste intéressante... Il faudrait sans doute que je trouve un moment pertinent pour clore et réouvrir la connexion permanente...
Merci de votre aide.
Jean-Yves
> Je pencherais assez pour un probleme du MiddleWare qui fait du pooling de
connection.
Avec dans l'application l'absence de Connection.close
Laurent.
Cela me parait être une piste intéressante...
Il faudrait sans doute que je trouve un moment pertinent pour clore et
réouvrir la connexion permanente...
> Je pencherais assez pour un probleme du MiddleWare qui fait du pooling de connection.
Avec dans l'application l'absence de Connection.close
Laurent.
Cela me parait être une piste intéressante... Il faudrait sans doute que je trouve un moment pertinent pour clore et réouvrir la connexion permanente...
Merci de votre aide.
Jean-Yves
Laurent Moreau
Pour etre honnete, j'ai le meme probleme sur un serveur: Machine 1: IIS / ASP / ADO Machine 2: SQL2K
Dans SQL Serveur je vois certaines connections présentent depuis tres longtemps. Assez étonnant, les connections dont la date du dernier lot est 1/1/1900 00:00:00
un petit sp_who2 : SPID Status Login HostName BlkBy DBName Command CPUTime DiskIO LastBatch ProgramName SPID ----- ------------------------------ --------------------------------------- - ---------------- ----- --------------- ---------------- --------- ------ - ------------- ---------------------------------------------- ----- 51 sleeping login1 Host1 . MaBase1 AWAITING COMMAND 421 0 06/08 04:30:1 Microsoft(R) Windows (R) 2000 Operating System 51 52 sleeping login2 Host2 . MaBase2 AWAITING COMMAND 0 0 01/01 00:00:0 Microsoft(R) Windows (R) 2000 Operating System 52
un petit sp_lock: spid dbid ObjId IndId Type Resource Mode Status ------ ------ ----------- ------ ---- ---------------- -------- ------ 51 161 0 0 DB S GRANT 52 66 0 0 DB S GRANT
J'ai 100 a 150 connections comme cela. (entre 10 et 26 par jours, certains jours aucune)
Je n'ai pas eu (pris plutot.....) le temps de résoudre le problème, quand ça me prend j'arrete et relance IIS. Mes pistes, mes idées: Absence de connection.close, dans les prog source. Normalement la connection ne persiste pas, le close est implicite, sauf si peut-etre j'ai une version de MDAC différente côté client et serveur ???? Car c'est ADO qui gere le pooling des connections. Pour les connections qui ont une date de dernier lot, voici l'instruction: sp_cursorclose;1 Naturellement je me suis penché vers les proc qui ont des cursors, j'ai rien trouvé Mais il me semble que SQL Server utilise un cursor si dans un lot d'instruction il y a plusieurs instructions. (2 select a la suite par exemple) Une piste a ne pas négliger: les connexions persistante ont toute une date de connexion comprise entre 3 et 5h du mat. Ce creneau horaire correspond au passage d'un automate de statistiques qui scrute les pages asp.
Je vais faire un tour sur les KB et les NG SQL server US.
Si je trouve quelque chose, je te tiens au courrant.
Laurent.
"Jean-Yves FREMONT" wrote in message news:
> Je pencherais assez pour un probleme du MiddleWare qui fait du pooling
de
> connection. > > Avec dans l'application l'absence de Connection.close > > > Laurent. >
Cela me parait être une piste intéressante... Il faudrait sans doute que je trouve un moment pertinent pour clore et réouvrir la connexion permanente...
Merci de votre aide.
Jean-Yves
Pour etre honnete, j'ai le meme probleme sur un serveur:
Machine 1: IIS / ASP / ADO
Machine 2: SQL2K
Dans SQL Serveur je vois certaines connections présentent depuis tres
longtemps.
Assez étonnant, les connections dont la date du dernier lot est 1/1/1900
00:00:00
un petit sp_who2 :
SPID Status Login
HostName BlkBy DBName Command CPUTime DiskIO
LastBatch ProgramName SPID
----- ------------------------------ ---------------------------------------
- ---------------- ----- --------------- ---------------- --------- ------ -
------------- ---------------------------------------------- -----
51 sleeping login1
Host1 . MaBase1 AWAITING COMMAND 421 0 06/08
04:30:1 Microsoft(R) Windows (R) 2000 Operating System 51
52 sleeping login2 Host2
. MaBase2 AWAITING COMMAND 0 0 01/01 00:00:0
Microsoft(R) Windows (R) 2000 Operating System 52
un petit sp_lock:
spid dbid ObjId IndId Type Resource Mode Status
------ ------ ----------- ------ ---- ---------------- -------- ------
51 161 0 0 DB S GRANT
52 66 0 0 DB S GRANT
J'ai 100 a 150 connections comme cela.
(entre 10 et 26 par jours, certains jours aucune)
Je n'ai pas eu (pris plutot.....) le temps de résoudre le problème, quand ça
me prend j'arrete et relance IIS.
Mes pistes, mes idées:
Absence de connection.close, dans les prog source. Normalement la
connection ne persiste pas, le close est implicite, sauf si peut-etre j'ai
une version de MDAC différente côté client et serveur ???? Car c'est ADO qui
gere le pooling des connections.
Pour les connections qui ont une date de dernier lot, voici l'instruction:
sp_cursorclose;1
Naturellement je me suis penché vers les proc qui ont des cursors, j'ai rien
trouvé
Mais il me semble que SQL Server utilise un cursor si dans un lot
d'instruction il y a plusieurs instructions. (2 select a la suite par
exemple)
Une piste a ne pas négliger: les connexions persistante ont toute une date
de connexion comprise entre 3 et 5h du mat.
Ce creneau horaire correspond au passage d'un automate de statistiques qui
scrute les pages asp.
Je vais faire un tour sur les KB et les NG SQL server US.
Si je trouve quelque chose, je te tiens au courrant.
Laurent.
"Jean-Yves FREMONT" <Jean-Yves.Fremont@crous-rouen.fr> wrote in message
news:emlozfeWEHA.3944@tk2msftngp13.phx.gbl...
> Je pencherais assez pour un probleme du MiddleWare qui fait du pooling
de
> connection.
>
> Avec dans l'application l'absence de Connection.close
>
>
> Laurent.
>
Cela me parait être une piste intéressante...
Il faudrait sans doute que je trouve un moment pertinent pour clore et
réouvrir la connexion permanente...
Pour etre honnete, j'ai le meme probleme sur un serveur: Machine 1: IIS / ASP / ADO Machine 2: SQL2K
Dans SQL Serveur je vois certaines connections présentent depuis tres longtemps. Assez étonnant, les connections dont la date du dernier lot est 1/1/1900 00:00:00
un petit sp_who2 : SPID Status Login HostName BlkBy DBName Command CPUTime DiskIO LastBatch ProgramName SPID ----- ------------------------------ --------------------------------------- - ---------------- ----- --------------- ---------------- --------- ------ - ------------- ---------------------------------------------- ----- 51 sleeping login1 Host1 . MaBase1 AWAITING COMMAND 421 0 06/08 04:30:1 Microsoft(R) Windows (R) 2000 Operating System 51 52 sleeping login2 Host2 . MaBase2 AWAITING COMMAND 0 0 01/01 00:00:0 Microsoft(R) Windows (R) 2000 Operating System 52
un petit sp_lock: spid dbid ObjId IndId Type Resource Mode Status ------ ------ ----------- ------ ---- ---------------- -------- ------ 51 161 0 0 DB S GRANT 52 66 0 0 DB S GRANT
J'ai 100 a 150 connections comme cela. (entre 10 et 26 par jours, certains jours aucune)
Je n'ai pas eu (pris plutot.....) le temps de résoudre le problème, quand ça me prend j'arrete et relance IIS. Mes pistes, mes idées: Absence de connection.close, dans les prog source. Normalement la connection ne persiste pas, le close est implicite, sauf si peut-etre j'ai une version de MDAC différente côté client et serveur ???? Car c'est ADO qui gere le pooling des connections. Pour les connections qui ont une date de dernier lot, voici l'instruction: sp_cursorclose;1 Naturellement je me suis penché vers les proc qui ont des cursors, j'ai rien trouvé Mais il me semble que SQL Server utilise un cursor si dans un lot d'instruction il y a plusieurs instructions. (2 select a la suite par exemple) Une piste a ne pas négliger: les connexions persistante ont toute une date de connexion comprise entre 3 et 5h du mat. Ce creneau horaire correspond au passage d'un automate de statistiques qui scrute les pages asp.
Je vais faire un tour sur les KB et les NG SQL server US.
Si je trouve quelque chose, je te tiens au courrant.
Laurent.
"Jean-Yves FREMONT" wrote in message news:
> Je pencherais assez pour un probleme du MiddleWare qui fait du pooling
de
> connection. > > Avec dans l'application l'absence de Connection.close > > > Laurent. >
Cela me parait être une piste intéressante... Il faudrait sans doute que je trouve un moment pertinent pour clore et réouvrir la connexion permanente...
> Je pencherais assez pour un probleme du MiddleWare qui fait du pooling
de
> connection. > > Avec dans l'application l'absence de Connection.close > > > Laurent. >
Cela me parait être une piste intéressante... Il faudrait sans doute que je trouve un moment pertinent pour clore et réouvrir la connexion permanente...
"Jean-Yves FREMONT" <Jean-Yves.Fremont@crous-rouen.fr> wrote in message
news:emlozfeWEHA.3944@tk2msftngp13.phx.gbl...
> Je pencherais assez pour un probleme du MiddleWare qui fait du pooling
de
> connection.
>
> Avec dans l'application l'absence de Connection.close
>
>
> Laurent.
>
Cela me parait être une piste intéressante...
Il faudrait sans doute que je trouve un moment pertinent pour clore et
réouvrir la connexion permanente...
> Je pencherais assez pour un probleme du MiddleWare qui fait du pooling
de
> connection. > > Avec dans l'application l'absence de Connection.close > > > Laurent. >
Cela me parait être une piste intéressante... Il faudrait sans doute que je trouve un moment pertinent pour clore et réouvrir la connexion permanente...
Merci de votre aide.
Jean-Yves
Fred BROUARD
si ton JDBC est paramétré au niveau d'isolation SERIALIZABLE par défaut, alors => contention.
Je ne suis pas spécialiste JDBC donc ne peut t'en dire plus.
De toute façon il est préférable de refermer les connexions le plus sousvent et le plus rapidement possible afin de libérer des ressources.
Si je t'ai demandé si tu avait été formé, c'est parce que le niveau d'isolation des transaction est un élément FONDAMENTAL du développement. Je m'étonne que tu ne le connaisse pas, ce qui me laisse à penser que tu as été mal formé...
Le niveau d'isolation par défaut de SQL Server est READ COMMITED. Certains middleware le force à SERIALIZABLE, empêchant ainsi toute concurrence (une seule requête à la fois). Le principe est de le piloter en fonction de ses besoisn et pour chaque transaction.
La meilleure façon de faire étant de passer toutes les MAJ (INSERT, UPDATE, DELETE) par des procédures stockées.
Tu trouvera tous les renseignements sur comment faire cela sur mon site web. Notamment : http://sqlpro.developpez.com/TransactSQL/SQL_MSTransactSQL.html#4.6
Quand à savoir si je suis gentil... Aux dires de certains... NON ! Mais je suis pas là pour être gentil, mais pro ! ;-)
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 *************************
Jean-Yves FREMONT a écrit:
...
il est important de connaître le middleware afin de savoir comment il se
comporte :
ODBC ? ADO ? BDE ? ???
JDBC, of course...
2) quel est le niveau d'isolation par défaut du middleware ?
Euh... Cékoiça ?... ;-)
Il serait temps de se préoccuper de cela car c'est sans doute le point le
plus bloquant !
3) s'agit-il uniquement de requêtes SQL ou a t-on eût recours
systématiquement à des procédures stockées pour faire les INSERT / UPDATE / DELETE ?
Tous les INSERT / UPDATE / DELETE sont effectués par des requêtes issues
de
l'application. Pas de procédures stockées, quelques déclencheurs pour date de création
/
modification des enregistrements.
C'est bien dommage, le meilleur conseil que je puisse vous donner dans
l'immédiat est de ré écrire l'application en
utilisant SYSTÉMATIQUEMENT des procédures stockées transactionnées en
pilotant le niveau d'isolation des transactions.
il est gentil...
Vous trouverez quelques informations sur mon site à condition d'avoir du
temps et du courage.
Petite question : avez-vous été formé avant d'utiliser SQL Server ?
... un peu méprisant, mais gentil.
A +
Merci pour vos conseils, anyway. ;-)
-- 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 *************************
si ton JDBC est paramétré au niveau d'isolation SERIALIZABLE par défaut, alors
=> contention.
Je ne suis pas spécialiste JDBC donc ne peut t'en dire plus.
De toute façon il est préférable de refermer les connexions le plus sousvent et
le plus rapidement possible afin de libérer des ressources.
Si je t'ai demandé si tu avait été formé, c'est parce que le niveau d'isolation
des transaction est un élément FONDAMENTAL du développement. Je m'étonne que tu
ne le connaisse pas, ce qui me laisse à penser que tu as été mal formé...
Le niveau d'isolation par défaut de SQL Server est READ COMMITED. Certains
middleware le force à SERIALIZABLE, empêchant ainsi toute concurrence (une seule
requête à la fois). Le principe est de le piloter en fonction de ses besoisn et
pour chaque transaction.
La meilleure façon de faire étant de passer toutes les MAJ (INSERT, UPDATE,
DELETE) par des procédures stockées.
Tu trouvera tous les renseignements sur comment faire cela sur mon site web.
Notamment : http://sqlpro.developpez.com/TransactSQL/SQL_MSTransactSQL.html#4.6
Quand à savoir si je suis gentil... Aux dires de certains... NON !
Mais je suis pas là pour être gentil, mais pro ! ;-)
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 *************************
Jean-Yves FREMONT a écrit:
...
il est important de connaître le middleware afin de savoir comment il se
comporte :
ODBC ? ADO ? BDE ? ???
JDBC, of course...
2) quel est le niveau d'isolation par défaut du middleware ?
Euh... Cékoiça ?... ;-)
Il serait temps de se préoccuper de cela car c'est sans doute le point le
plus bloquant !
3) s'agit-il uniquement de requêtes SQL ou a t-on eût recours
systématiquement à des procédures stockées pour faire les
INSERT / UPDATE / DELETE ?
Tous les INSERT / UPDATE / DELETE sont effectués par des requêtes issues
de
l'application.
Pas de procédures stockées, quelques déclencheurs pour date de création
/
modification des enregistrements.
C'est bien dommage, le meilleur conseil que je puisse vous donner dans
l'immédiat est de ré écrire l'application en
utilisant SYSTÉMATIQUEMENT des procédures stockées transactionnées en
pilotant le niveau d'isolation des transactions.
il est gentil...
Vous trouverez quelques informations sur mon site à condition d'avoir du
temps et du courage.
Petite question : avez-vous été formé avant d'utiliser SQL Server ?
... un peu méprisant, mais gentil.
A +
Merci pour vos conseils, anyway. ;-)
--
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 *************************
si ton JDBC est paramétré au niveau d'isolation SERIALIZABLE par défaut, alors => contention.
Je ne suis pas spécialiste JDBC donc ne peut t'en dire plus.
De toute façon il est préférable de refermer les connexions le plus sousvent et le plus rapidement possible afin de libérer des ressources.
Si je t'ai demandé si tu avait été formé, c'est parce que le niveau d'isolation des transaction est un élément FONDAMENTAL du développement. Je m'étonne que tu ne le connaisse pas, ce qui me laisse à penser que tu as été mal formé...
Le niveau d'isolation par défaut de SQL Server est READ COMMITED. Certains middleware le force à SERIALIZABLE, empêchant ainsi toute concurrence (une seule requête à la fois). Le principe est de le piloter en fonction de ses besoisn et pour chaque transaction.
La meilleure façon de faire étant de passer toutes les MAJ (INSERT, UPDATE, DELETE) par des procédures stockées.
Tu trouvera tous les renseignements sur comment faire cela sur mon site web. Notamment : http://sqlpro.developpez.com/TransactSQL/SQL_MSTransactSQL.html#4.6
Quand à savoir si je suis gentil... Aux dires de certains... NON ! Mais je suis pas là pour être gentil, mais pro ! ;-)
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 *************************
Jean-Yves FREMONT a écrit:
...
il est important de connaître le middleware afin de savoir comment il se
comporte :
ODBC ? ADO ? BDE ? ???
JDBC, of course...
2) quel est le niveau d'isolation par défaut du middleware ?
Euh... Cékoiça ?... ;-)
Il serait temps de se préoccuper de cela car c'est sans doute le point le
plus bloquant !
3) s'agit-il uniquement de requêtes SQL ou a t-on eût recours
systématiquement à des procédures stockées pour faire les INSERT / UPDATE / DELETE ?
Tous les INSERT / UPDATE / DELETE sont effectués par des requêtes issues
de
l'application. Pas de procédures stockées, quelques déclencheurs pour date de création
/
modification des enregistrements.
C'est bien dommage, le meilleur conseil que je puisse vous donner dans
l'immédiat est de ré écrire l'application en
utilisant SYSTÉMATIQUEMENT des procédures stockées transactionnées en
pilotant le niveau d'isolation des transactions.
il est gentil...
Vous trouverez quelques informations sur mon site à condition d'avoir du
temps et du courage.
Petite question : avez-vous été formé avant d'utiliser SQL Server ?
... un peu méprisant, mais gentil.
A +
Merci pour vos conseils, anyway. ;-)
-- 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 *************************
