Bonjour,
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 ?
Merci d'avance pour votre aide.
Bonjour,
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 ?
Merci d'avance pour votre aide.
Bonjour,
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 ?
Merci d'avance pour votre aide.
1) tout d'abord comment se fait la connexion entre l'appli Java et le
d'un mode déconnecté ? Client léger ou client lourd ???
2) quel est le niveau d'isolation par défaut du middleware ?
3) s'agit-il uniquement de requêtes SQL ou a t-on eût recours
INSERT / UPDATE / DELETE ?
4) le JT ne peut être tronqué que si une sauvegarde du JT a eût lieu !
C'est une question plus que récurente puisque venant au moins 3 fois par
Pourquoi ce comportement ?
Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer
sont pas tronqués, la récupération est en principe toujours possible.
n'a pas eut lieu, il n'est pas possible de tronquer les fichiers. Et la
sauvegarde de la base a déjà eût lieu.
1) tout d'abord comment se fait la connexion entre l'appli Java et le
d'un mode déconnecté ? Client léger ou client lourd ???
2) quel est le niveau d'isolation par défaut du middleware ?
3) s'agit-il uniquement de requêtes SQL ou a t-on eût recours
INSERT / UPDATE / DELETE ?
4) le JT ne peut être tronqué que si une sauvegarde du JT a eût lieu !
C'est une question plus que récurente puisque venant au moins 3 fois par
Pourquoi ce comportement ?
Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer
sont pas tronqués, la récupération est en principe toujours possible.
n'a pas eut lieu, il n'est pas possible de tronquer les fichiers. Et la
sauvegarde de la base a déjà eût lieu.
1) tout d'abord comment se fait la connexion entre l'appli Java et le
d'un mode déconnecté ? Client léger ou client lourd ???
2) quel est le niveau d'isolation par défaut du middleware ?
3) s'agit-il uniquement de requêtes SQL ou a t-on eût recours
INSERT / UPDATE / DELETE ?
4) le JT ne peut être tronqué que si une sauvegarde du JT a eût lieu !
C'est une question plus que récurente puisque venant au moins 3 fois par
Pourquoi ce comportement ?
Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer
sont pas tronqués, la récupération est en principe toujours possible.
n'a pas eut lieu, il n'est pas possible de tronquer les fichiers. Et la
sauvegarde de la base a déjà eût lieu.
1) tout d'abord comment se fait la connexion entre l'appli Java et le
d'un mode déconnecté ? Client léger ou client lourd ???
2) quel est le niveau d'isolation par défaut du middleware ?
3) s'agit-il uniquement de requêtes SQL ou a t-on eût recours
INSERT / UPDATE / DELETE ?
4) le JT ne peut être tronqué que si une sauvegarde du JT a eût lieu !
C'est une question plus que récurente puisque venant au moins 3 fois par
Pourquoi ce comportement ?
Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer
sont pas tronqués, la récupération est en principe toujours possible.
n'a pas eut lieu, il n'est pas possible de tronquer les fichiers. Et la
sauvegarde de la base a déjà eût lieu.
1) tout d'abord comment se fait la connexion entre l'appli Java et le
d'un mode déconnecté ? Client léger ou client lourd ???
2) quel est le niveau d'isolation par défaut du middleware ?
3) s'agit-il uniquement de requêtes SQL ou a t-on eût recours
INSERT / UPDATE / DELETE ?
4) le JT ne peut être tronqué que si une sauvegarde du JT a eût lieu !
C'est une question plus que récurente puisque venant au moins 3 fois par
Pourquoi ce comportement ?
Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer
sont pas tronqués, la récupération est en principe toujours possible.
n'a pas eut lieu, il n'est pas possible de tronquer les fichiers. Et la
sauvegarde de la base a déjà eût lieu.
1) tout d'abord comment se fait la connexion entre l'appli Java et le
d'un mode déconnecté ? Client léger ou client lourd ???
2) quel est le niveau d'isolation par défaut du middleware ?
3) s'agit-il uniquement de requêtes SQL ou a t-on eût recours
INSERT / UPDATE / DELETE ?
4) le JT ne peut être tronqué que si une sauvegarde du JT a eût lieu !
C'est une question plus que récurente puisque venant au moins 3 fois par
Pourquoi ce comportement ?
Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer
sont pas tronqués, la récupération est en principe toujours possible.
n'a pas eut lieu, il n'est pas possible de tronquer les fichiers. Et la
sauvegarde de la base a déjà eût lieu.
Merci de réagir si rapidement...
Je vais essayer de vous fournir les éléments.1) tout d'abord comment se fait la connexion entre l'appli Java et le
server ? S'agit-il d'une connexion permanent oud'un mode déconnecté ? Client léger ou client lourd ???
Il s'agit d'une application web - client léger : les naviguateurs des
utilisateurs reçoivent et retournent des formulaires générés par des
servlets Java sur le serveur unique (NT2000 - Apache - Tomcat - SQLServer).
La connexion est permanente, je suppose... C'est l'application qui se
connecte avec un utilisateur unique et effectue les requêtes.
2) quel est le niveau d'isolation par défaut du middleware ?
Euh... Cékoiça ?... ;-)
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 lesINSERT / 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.
4) le JT ne peut être tronqué que si une sauvegarde du JT a eût lieu !
C'est une question plus que récurente puisque venant au moins 3 fois par
moi.Pourquoi ce comportement ?
Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer
une base corrompue. Tant que ces fichiers nesont pas tronqués, la récupération est en principe toujours possible.
C'est pourquoi tant que la sauvegarde du journaln'a pas eut lieu, il n'est pas possible de tronquer les fichiers. Et la
sauvegrade du journal n'est possible que si unesauvegarde de la base a déjà eût lieu.
La base est sauvegardée à 13h et 22h.
Le journal des transactions est sauvegardé (TRUNCATE) à 8h, 10h, 12h, 14h,
16h, 18h.
A la lumière de votre explication, seules les sauvegardes de 8h (après sauve
BD de 22h) et de 14h (après sauve BD de 13h) pourrait donc tronquer le
Journal des transactions ?...
Merci de réagir si rapidement...
Je vais essayer de vous fournir les éléments.
1) tout d'abord comment se fait la connexion entre l'appli Java et le
server ? S'agit-il d'une connexion permanent ou
d'un mode déconnecté ? Client léger ou client lourd ???
Il s'agit d'une application web - client léger : les naviguateurs des
utilisateurs reçoivent et retournent des formulaires générés par des
servlets Java sur le serveur unique (NT2000 - Apache - Tomcat - SQLServer).
La connexion est permanente, je suppose... C'est l'application qui se
connecte avec un utilisateur unique et effectue les requêtes.
2) quel est le niveau d'isolation par défaut du middleware ?
Euh... Cékoiça ?... ;-)
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.
4) le JT ne peut être tronqué que si une sauvegarde du JT a eût lieu !
C'est une question plus que récurente puisque venant au moins 3 fois par
moi.
Pourquoi ce comportement ?
Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer
une base corrompue. Tant que ces fichiers ne
sont pas tronqués, la récupération est en principe toujours possible.
C'est pourquoi tant que la sauvegarde du journal
n'a pas eut lieu, il n'est pas possible de tronquer les fichiers. Et la
sauvegrade du journal n'est possible que si une
sauvegarde de la base a déjà eût lieu.
La base est sauvegardée à 13h et 22h.
Le journal des transactions est sauvegardé (TRUNCATE) à 8h, 10h, 12h, 14h,
16h, 18h.
A la lumière de votre explication, seules les sauvegardes de 8h (après sauve
BD de 22h) et de 14h (après sauve BD de 13h) pourrait donc tronquer le
Journal des transactions ?...
Merci de réagir si rapidement...
Je vais essayer de vous fournir les éléments.1) tout d'abord comment se fait la connexion entre l'appli Java et le
server ? S'agit-il d'une connexion permanent oud'un mode déconnecté ? Client léger ou client lourd ???
Il s'agit d'une application web - client léger : les naviguateurs des
utilisateurs reçoivent et retournent des formulaires générés par des
servlets Java sur le serveur unique (NT2000 - Apache - Tomcat - SQLServer).
La connexion est permanente, je suppose... C'est l'application qui se
connecte avec un utilisateur unique et effectue les requêtes.
2) quel est le niveau d'isolation par défaut du middleware ?
Euh... Cékoiça ?... ;-)
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 lesINSERT / 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.
4) le JT ne peut être tronqué que si une sauvegarde du JT a eût lieu !
C'est une question plus que récurente puisque venant au moins 3 fois par
moi.Pourquoi ce comportement ?
Tout simplement par sécurité.
En effet les différentes sauvegardes : data ou log permettent de récupérer
une base corrompue. Tant que ces fichiers nesont pas tronqués, la récupération est en principe toujours possible.
C'est pourquoi tant que la sauvegarde du journaln'a pas eut lieu, il n'est pas possible de tronquer les fichiers. Et la
sauvegrade du journal n'est possible que si unesauvegarde de la base a déjà eût lieu.
La base est sauvegardée à 13h et 22h.
Le journal des transactions est sauvegardé (TRUNCATE) à 8h, 10h, 12h, 14h,
16h, 18h.
A la lumière de votre explication, seules les sauvegardes de 8h (après sauve
BD de 22h) et de 14h (après sauve BD de 13h) pourrait donc tronquer le
Journal des transactions ?...
il est important de connaître le middleware afin de savoir comment il se
ODBC ? ADO ? BDE ? ???
> >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
> >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
> 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
utilisant SYSTÉMATIQUEMENT des procédures stockées transactionnées en
Vous trouverez quelques informations sur mon site à condition d'avoir du
Petite question : avez-vous été formé avant d'utiliser SQL Server ?
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 *************************
il est important de connaître le middleware afin de savoir comment il se
ODBC ? ADO ? BDE ? ???
> >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
> >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
> 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
utilisant SYSTÉMATIQUEMENT des procédures stockées transactionnées en
Vous trouverez quelques informations sur mon site à condition d'avoir du
Petite question : avez-vous été formé avant d'utiliser SQL Server ?
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 *************************
il est important de connaître le middleware afin de savoir comment il se
ODBC ? ADO ? BDE ? ???
> >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
> >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
> 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
utilisant SYSTÉMATIQUEMENT des procédures stockées transactionnées en
Vous trouverez quelques informations sur mon site à condition d'avoir du
Petite question : avez-vous été formé avant d'utiliser SQL Server ?
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 *************************
il est important de connaître le middleware afin de savoir comment il se
ODBC ? ADO ? BDE ? ???
> >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
> >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
> 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
utilisant SYSTÉMATIQUEMENT des procédures stockées transactionnées en
Vous trouverez quelques informations sur mon site à condition d'avoir du
Petite question : avez-vous été formé avant d'utiliser SQL Server ?
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 *************************
il est important de connaître le middleware afin de savoir comment il se
ODBC ? ADO ? BDE ? ???
> >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
> >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
> 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
utilisant SYSTÉMATIQUEMENT des procédures stockées transactionnées en
Vous trouverez quelques informations sur mon site à condition d'avoir du
Petite question : avez-vous été formé avant d'utiliser SQL Server ?
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 *************************
il est important de connaître le middleware afin de savoir comment il se
ODBC ? ADO ? BDE ? ???
> >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
> >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
> 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
utilisant SYSTÉMATIQUEMENT des procédures stockées transactionnées en
Vous trouverez quelques informations sur mon site à condition d'avoir du
Petite question : avez-vous été formé avant d'utiliser SQL Server ?
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 *************************
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
Bonjour,
J'ai un souci concernant les processus actifs et les Verrous sur ma base
production...
Je développe une application en servlets Java qui effectue des requêtes
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 ?
Merci d'avance pour votre aide.
