Bonjour,
SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
Environnement fortement transactionnel avec forts volumes sur certaines
tables.
Base de données unique, respectant les règles de normalité.
Il semblerait que les procédures stockées créées via SQL Query Builder,
comme cela peut être le cas quand on recharge un script sauvegardé dans un
fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
l'intégralité des dépendances aux tables qu'elles utilisent.
Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
demande (via sp_recompile) le marquage à recompilation de toutes mes
procédures stockées, table par table, et au matin, les performances sont
CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées
SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
externe). La simple ouverture de certaines procédures stockées-clefs dans
SEM, un ajout puis une suppession d'un caractère n'importe où et une
de recompilation suffit à faire rentrer tout dans l'ordre...
J'en déduis que cette absence de dépendances sur ces procédures empêche
recompilation propre, et les statistiques fraîches de réindexation
déclenchent des recompilations parasites avec un contexte bâtard, qui
freinent leur exécution.
Je prends la moindre information.
Merci.
Jean-Yves AUGER
DBA
Limagrain Verneuil Holding
Bonjour,
SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
Environnement fortement transactionnel avec forts volumes sur certaines
tables.
Base de données unique, respectant les règles de normalité.
Il semblerait que les procédures stockées créées via SQL Query Builder,
comme cela peut être le cas quand on recharge un script sauvegardé dans un
fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
l'intégralité des dépendances aux tables qu'elles utilisent.
Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
demande (via sp_recompile) le marquage à recompilation de toutes mes
procédures stockées, table par table, et au matin, les performances sont
CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées
SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
externe). La simple ouverture de certaines procédures stockées-clefs dans
SEM, un ajout puis une suppession d'un caractère n'importe où et une
de recompilation suffit à faire rentrer tout dans l'ordre...
J'en déduis que cette absence de dépendances sur ces procédures empêche
recompilation propre, et les statistiques fraîches de réindexation
déclenchent des recompilations parasites avec un contexte bâtard, qui
freinent leur exécution.
Je prends la moindre information.
Merci.
Jean-Yves AUGER
DBA
Limagrain Verneuil Holding
Bonjour,
SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
Environnement fortement transactionnel avec forts volumes sur certaines
tables.
Base de données unique, respectant les règles de normalité.
Il semblerait que les procédures stockées créées via SQL Query Builder,
comme cela peut être le cas quand on recharge un script sauvegardé dans un
fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
l'intégralité des dépendances aux tables qu'elles utilisent.
Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
demande (via sp_recompile) le marquage à recompilation de toutes mes
procédures stockées, table par table, et au matin, les performances sont
CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées
SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
externe). La simple ouverture de certaines procédures stockées-clefs dans
SEM, un ajout puis une suppession d'un caractère n'importe où et une
de recompilation suffit à faire rentrer tout dans l'ordre...
J'en déduis que cette absence de dépendances sur ces procédures empêche
recompilation propre, et les statistiques fraîches de réindexation
déclenchent des recompilations parasites avec un contexte bâtard, qui
freinent leur exécution.
Je prends la moindre information.
Merci.
Jean-Yves AUGER
DBA
Limagrain Verneuil Holding
Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un de
mes clients.
SET NOCOUNT ON
DECLARE @CurObjectName nvarchar(200) -- Table or view name
----
-- Tables and Views recompilation
----
DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
name
OPEN My_TableCursor
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
WHILE (@@fetch_status = 0)
BEGIN
EXEC( N'update statistics ' + @CurObjectName)
EXEC (N'exec sp_recompile ' + @CurObjectName)
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
END
CLOSE My_TableCursor
DEALLOCATE My_TableCursor
Phil.
"Jean-Yves" wrote in message
news:
> Bonjour,
>
> SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> Environnement fortement transactionnel avec forts volumes sur certaines
> tables.
> Base de données unique, respectant les règles de normalité.
>
> Il semblerait que les procédures stockées créées via SQL Query Builder,
> comme cela peut être le cas quand on recharge un script sauvegardé dans un
> fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> l'intégralité des dépendances aux tables qu'elles utilisent.
>
> Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
> demande (via sp_recompile) le marquage à recompilation de toutes mes
> procédures stockées, table par table, et au matin, les performances sont
> CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées
via
> SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> externe). La simple ouverture de certaines procédures stockées-clefs dans
> SEM, un ajout puis une suppession d'un caractère n'importe où et une
demande
> de recompilation suffit à faire rentrer tout dans l'ordre...
>
> J'en déduis que cette absence de dépendances sur ces procédures empêche
leur
> recompilation propre, et les statistiques fraîches de réindexation
> déclenchent des recompilations parasites avec un contexte bâtard, qui
> freinent leur exécution.
>
> Je prends la moindre information.
> Merci.
>
> Jean-Yves AUGER
> DBA
> Limagrain Verneuil Holding
Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un de
mes clients.
SET NOCOUNT ON
DECLARE @CurObjectName nvarchar(200) -- Table or view name
----
-- Tables and Views recompilation
----
DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
name
OPEN My_TableCursor
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
WHILE (@@fetch_status = 0)
BEGIN
EXEC( N'update statistics ' + @CurObjectName)
EXEC (N'exec sp_recompile ' + @CurObjectName)
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
END
CLOSE My_TableCursor
DEALLOCATE My_TableCursor
Phil.
"Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
news:2F9C1F31-EBAE-4F11-B7B8-2E0B9E7540AF@microsoft.com...
> Bonjour,
>
> SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> Environnement fortement transactionnel avec forts volumes sur certaines
> tables.
> Base de données unique, respectant les règles de normalité.
>
> Il semblerait que les procédures stockées créées via SQL Query Builder,
> comme cela peut être le cas quand on recharge un script sauvegardé dans un
> fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> l'intégralité des dépendances aux tables qu'elles utilisent.
>
> Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
> demande (via sp_recompile) le marquage à recompilation de toutes mes
> procédures stockées, table par table, et au matin, les performances sont
> CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées
via
> SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> externe). La simple ouverture de certaines procédures stockées-clefs dans
> SEM, un ajout puis une suppession d'un caractère n'importe où et une
demande
> de recompilation suffit à faire rentrer tout dans l'ordre...
>
> J'en déduis que cette absence de dépendances sur ces procédures empêche
leur
> recompilation propre, et les statistiques fraîches de réindexation
> déclenchent des recompilations parasites avec un contexte bâtard, qui
> freinent leur exécution.
>
> Je prends la moindre information.
> Merci.
>
> Jean-Yves AUGER
> DBA
> Limagrain Verneuil Holding
Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un de
mes clients.
SET NOCOUNT ON
DECLARE @CurObjectName nvarchar(200) -- Table or view name
----
-- Tables and Views recompilation
----
DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
name
OPEN My_TableCursor
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
WHILE (@@fetch_status = 0)
BEGIN
EXEC( N'update statistics ' + @CurObjectName)
EXEC (N'exec sp_recompile ' + @CurObjectName)
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
END
CLOSE My_TableCursor
DEALLOCATE My_TableCursor
Phil.
"Jean-Yves" wrote in message
news:
> Bonjour,
>
> SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> Environnement fortement transactionnel avec forts volumes sur certaines
> tables.
> Base de données unique, respectant les règles de normalité.
>
> Il semblerait que les procédures stockées créées via SQL Query Builder,
> comme cela peut être le cas quand on recharge un script sauvegardé dans un
> fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> l'intégralité des dépendances aux tables qu'elles utilisent.
>
> Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
> demande (via sp_recompile) le marquage à recompilation de toutes mes
> procédures stockées, table par table, et au matin, les performances sont
> CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées
via
> SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> externe). La simple ouverture de certaines procédures stockées-clefs dans
> SEM, un ajout puis une suppession d'un caractère n'importe où et une
demande
> de recompilation suffit à faire rentrer tout dans l'ordre...
>
> J'en déduis que cette absence de dépendances sur ces procédures empêche
leur
> recompilation propre, et les statistiques fraîches de réindexation
> déclenchent des recompilations parasites avec un contexte bâtard, qui
> freinent leur exécution.
>
> Je prends la moindre information.
> Merci.
>
> Jean-Yves AUGER
> DBA
> Limagrain Verneuil Holding
Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un de
mes clients.
SET NOCOUNT ON
DECLARE @CurObjectName nvarchar(200) -- Table or view name
----
-- Tables and Views recompilation
----
DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
name
OPEN My_TableCursor
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
WHILE (@@fetch_status = 0)
BEGIN
EXEC( N'update statistics ' + @CurObjectName)
EXEC (N'exec sp_recompile ' + @CurObjectName)
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
END
CLOSE My_TableCursor
DEALLOCATE My_TableCursor
Phil.
"Jean-Yves" wrote in message
news:
> Bonjour,
>
> SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> Environnement fortement transactionnel avec forts volumes sur certaines
> tables.
> Base de données unique, respectant les règles de normalité.
>
> Il semblerait que les procédures stockées créées via SQL Query Builder,
> comme cela peut être le cas quand on recharge un script sauvegardé dans un
> fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> l'intégralité des dépendances aux tables qu'elles utilisent.
>
> Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
> demande (via sp_recompile) le marquage à recompilation de toutes mes
> procédures stockées, table par table, et au matin, les performances sont
> CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées
via
> SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> externe). La simple ouverture de certaines procédures stockées-clefs dans
> SEM, un ajout puis une suppession d'un caractère n'importe où et une
demande
> de recompilation suffit à faire rentrer tout dans l'ordre...
>
> J'en déduis que cette absence de dépendances sur ces procédures empêche
leur
> recompilation propre, et les statistiques fraîches de réindexation
> déclenchent des recompilations parasites avec un contexte bâtard, qui
> freinent leur exécution.
>
> Je prends la moindre information.
> Merci.
>
> Jean-Yves AUGER
> DBA
> Limagrain Verneuil Holding
Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un de
mes clients.
SET NOCOUNT ON
DECLARE @CurObjectName nvarchar(200) -- Table or view name
----
-- Tables and Views recompilation
----
DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
name
OPEN My_TableCursor
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
WHILE (@@fetch_status = 0)
BEGIN
EXEC( N'update statistics ' + @CurObjectName)
EXEC (N'exec sp_recompile ' + @CurObjectName)
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
END
CLOSE My_TableCursor
DEALLOCATE My_TableCursor
Phil.
"Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
news:2F9C1F31-EBAE-4F11-B7B8-2E0B9E7540AF@microsoft.com...
> Bonjour,
>
> SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> Environnement fortement transactionnel avec forts volumes sur certaines
> tables.
> Base de données unique, respectant les règles de normalité.
>
> Il semblerait que les procédures stockées créées via SQL Query Builder,
> comme cela peut être le cas quand on recharge un script sauvegardé dans un
> fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> l'intégralité des dépendances aux tables qu'elles utilisent.
>
> Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
> demande (via sp_recompile) le marquage à recompilation de toutes mes
> procédures stockées, table par table, et au matin, les performances sont
> CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées
via
> SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> externe). La simple ouverture de certaines procédures stockées-clefs dans
> SEM, un ajout puis une suppession d'un caractère n'importe où et une
demande
> de recompilation suffit à faire rentrer tout dans l'ordre...
>
> J'en déduis que cette absence de dépendances sur ces procédures empêche
leur
> recompilation propre, et les statistiques fraîches de réindexation
> déclenchent des recompilations parasites avec un contexte bâtard, qui
> freinent leur exécution.
>
> Je prends la moindre information.
> Merci.
>
> Jean-Yves AUGER
> DBA
> Limagrain Verneuil Holding
Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un de
mes clients.
SET NOCOUNT ON
DECLARE @CurObjectName nvarchar(200) -- Table or view name
----
-- Tables and Views recompilation
----
DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
name
OPEN My_TableCursor
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
WHILE (@@fetch_status = 0)
BEGIN
EXEC( N'update statistics ' + @CurObjectName)
EXEC (N'exec sp_recompile ' + @CurObjectName)
FETCH NEXT FROM My_TableCursor INTO @CurObjectName
END
CLOSE My_TableCursor
DEALLOCATE My_TableCursor
Phil.
"Jean-Yves" wrote in message
news:
> Bonjour,
>
> SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> Environnement fortement transactionnel avec forts volumes sur certaines
> tables.
> Base de données unique, respectant les règles de normalité.
>
> Il semblerait que les procédures stockées créées via SQL Query Builder,
> comme cela peut être le cas quand on recharge un script sauvegardé dans un
> fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> l'intégralité des dépendances aux tables qu'elles utilisent.
>
> Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
> demande (via sp_recompile) le marquage à recompilation de toutes mes
> procédures stockées, table par table, et au matin, les performances sont
> CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées
via
> SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> externe). La simple ouverture de certaines procédures stockées-clefs dans
> SEM, un ajout puis une suppession d'un caractère n'importe où et une
demande
> de recompilation suffit à faire rentrer tout dans l'ordre...
>
> J'en déduis que cette absence de dépendances sur ces procédures empêche
leur
> recompilation propre, et les statistiques fraîches de réindexation
> déclenchent des recompilations parasites avec un contexte bâtard, qui
> freinent leur exécution.
>
> Je prends la moindre information.
> Merci.
>
> Jean-Yves AUGER
> DBA
> Limagrain Verneuil Holding
Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
recompilation les procédures dépendantes de mes 291 tables, ta méthode a
1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
même.
Merci quand même.
"Philippe [MS]" a écrit :
> Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
> mes clients.
>
> SET NOCOUNT ON
>
> DECLARE @CurObjectName nvarchar(200) -- Table or view name
>
> ----
> -- Tables and Views recompilation
> ----
> DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> name
>
> OPEN My_TableCursor
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> WHILE (@@fetch_status = 0)
> BEGIN
> EXEC( N'update statistics ' + @CurObjectName)
> EXEC (N'exec sp_recompile ' + @CurObjectName)
>
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> END
> CLOSE My_TableCursor
> DEALLOCATE My_TableCursor
>
>
> Phil.
>
> "Jean-Yves" wrote in message
> news:
> > Bonjour,
> >
> > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > Environnement fortement transactionnel avec forts volumes sur
> > tables.
> > Base de données unique, respectant les règles de normalité.
> >
> > Il semblerait que les procédures stockées créées via SQL Query
> > comme cela peut être le cas quand on recharge un script sauvegardé
> > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > l'intégralité des dépendances aux tables qu'elles utilisent.
> >
> > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
> > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > procédures stockées, table par table, et au matin, les performances
> > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
> via
> > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > externe). La simple ouverture de certaines procédures stockées-clefs
> > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> demande
> > de recompilation suffit à faire rentrer tout dans l'ordre...
> >
> > J'en déduis que cette absence de dépendances sur ces procédures
> leur
> > recompilation propre, et les statistiques fraîches de réindexation
> > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > freinent leur exécution.
> >
> > Je prends la moindre information.
> > Merci.
> >
> > Jean-Yves AUGER
> > DBA
> > Limagrain Verneuil Holding
>
>
>
Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
recompilation les procédures dépendantes de mes 291 tables, ta méthode a
1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
même.
Merci quand même.
"Philippe [MS]" a écrit :
> Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
> mes clients.
>
> SET NOCOUNT ON
>
> DECLARE @CurObjectName nvarchar(200) -- Table or view name
>
> ----
> -- Tables and Views recompilation
> ----
> DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> name
>
> OPEN My_TableCursor
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> WHILE (@@fetch_status = 0)
> BEGIN
> EXEC( N'update statistics ' + @CurObjectName)
> EXEC (N'exec sp_recompile ' + @CurObjectName)
>
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> END
> CLOSE My_TableCursor
> DEALLOCATE My_TableCursor
>
>
> Phil.
>
> "Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
> news:2F9C1F31-EBAE-4F11-B7B8-2E0B9E7540AF@microsoft.com...
> > Bonjour,
> >
> > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > Environnement fortement transactionnel avec forts volumes sur
> > tables.
> > Base de données unique, respectant les règles de normalité.
> >
> > Il semblerait que les procédures stockées créées via SQL Query
> > comme cela peut être le cas quand on recharge un script sauvegardé
> > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > l'intégralité des dépendances aux tables qu'elles utilisent.
> >
> > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
> > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > procédures stockées, table par table, et au matin, les performances
> > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
> via
> > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > externe). La simple ouverture de certaines procédures stockées-clefs
> > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> demande
> > de recompilation suffit à faire rentrer tout dans l'ordre...
> >
> > J'en déduis que cette absence de dépendances sur ces procédures
> leur
> > recompilation propre, et les statistiques fraîches de réindexation
> > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > freinent leur exécution.
> >
> > Je prends la moindre information.
> > Merci.
> >
> > Jean-Yves AUGER
> > DBA
> > Limagrain Verneuil Holding
>
>
>
Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
recompilation les procédures dépendantes de mes 291 tables, ta méthode a
1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
même.
Merci quand même.
"Philippe [MS]" a écrit :
> Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
> mes clients.
>
> SET NOCOUNT ON
>
> DECLARE @CurObjectName nvarchar(200) -- Table or view name
>
> ----
> -- Tables and Views recompilation
> ----
> DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> name
>
> OPEN My_TableCursor
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> WHILE (@@fetch_status = 0)
> BEGIN
> EXEC( N'update statistics ' + @CurObjectName)
> EXEC (N'exec sp_recompile ' + @CurObjectName)
>
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> END
> CLOSE My_TableCursor
> DEALLOCATE My_TableCursor
>
>
> Phil.
>
> "Jean-Yves" wrote in message
> news:
> > Bonjour,
> >
> > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > Environnement fortement transactionnel avec forts volumes sur
> > tables.
> > Base de données unique, respectant les règles de normalité.
> >
> > Il semblerait que les procédures stockées créées via SQL Query
> > comme cela peut être le cas quand on recharge un script sauvegardé
> > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > l'intégralité des dépendances aux tables qu'elles utilisent.
> >
> > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
> > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > procédures stockées, table par table, et au matin, les performances
> > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
> via
> > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > externe). La simple ouverture de certaines procédures stockées-clefs
> > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> demande
> > de recompilation suffit à faire rentrer tout dans l'ordre...
> >
> > J'en déduis que cette absence de dépendances sur ces procédures
> leur
> > recompilation propre, et les statistiques fraîches de réindexation
> > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > freinent leur exécution.
> >
> > Je prends la moindre information.
> > Merci.
> >
> > Jean-Yves AUGER
> > DBA
> > Limagrain Verneuil Holding
>
>
>
Avez vous essayé l'ajout d'un "dbcc freeproccache" en fin de votre batch?
--
Cdlt,
FP
"Jean-Yves" wrote in message
news:
> Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
> recompilation les procédures dépendantes de mes 291 tables, ta méthode a
mis
> 1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
> même.
> Merci quand même.
>
> "Philippe [MS]" a écrit :
>
> > Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
de
> > mes clients.
> >
> > SET NOCOUNT ON
> >
> > DECLARE @CurObjectName nvarchar(200) -- Table or view name
> >
> > ----
> > -- Tables and Views recompilation
> > ----
> > DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> > SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> > name
> >
> > OPEN My_TableCursor
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > WHILE (@@fetch_status = 0)
> > BEGIN
> > EXEC( N'update statistics ' + @CurObjectName)
> > EXEC (N'exec sp_recompile ' + @CurObjectName)
> >
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > END
> > CLOSE My_TableCursor
> > DEALLOCATE My_TableCursor
> >
> >
> > Phil.
> >
> > "Jean-Yves" wrote in message
> > news:
> > > Bonjour,
> > >
> > > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > > Environnement fortement transactionnel avec forts volumes sur
certaines
> > > tables.
> > > Base de données unique, respectant les règles de normalité.
> > >
> > > Il semblerait que les procédures stockées créées via SQL Query
Builder,
> > > comme cela peut être le cas quand on recharge un script sauvegardé
dans un
> > > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > > l'intégralité des dépendances aux tables qu'elles utilisent.
> > >
> > > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
je
> > > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > > procédures stockées, table par table, et au matin, les performances
sont
> > > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
créées
> > via
> > > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > > externe). La simple ouverture de certaines procédures stockées-clefs
dans
> > > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> > demande
> > > de recompilation suffit à faire rentrer tout dans l'ordre...
> > >
> > > J'en déduis que cette absence de dépendances sur ces procédures
empêche
> > leur
> > > recompilation propre, et les statistiques fraîches de réindexation
> > > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > > freinent leur exécution.
> > >
> > > Je prends la moindre information.
> > > Merci.
> > >
> > > Jean-Yves AUGER
> > > DBA
> > > Limagrain Verneuil Holding
> >
> >
> >
Avez vous essayé l'ajout d'un "dbcc freeproccache" en fin de votre batch?
--
Cdlt,
FP
"Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
news:2509319C-DCD1-4CF9-9C1B-416D4BF88C13@microsoft.com...
> Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
> recompilation les procédures dépendantes de mes 291 tables, ta méthode a
mis
> 1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
> même.
> Merci quand même.
>
> "Philippe [MS]" a écrit :
>
> > Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
de
> > mes clients.
> >
> > SET NOCOUNT ON
> >
> > DECLARE @CurObjectName nvarchar(200) -- Table or view name
> >
> > ----
> > -- Tables and Views recompilation
> > ----
> > DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> > SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> > name
> >
> > OPEN My_TableCursor
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > WHILE (@@fetch_status = 0)
> > BEGIN
> > EXEC( N'update statistics ' + @CurObjectName)
> > EXEC (N'exec sp_recompile ' + @CurObjectName)
> >
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > END
> > CLOSE My_TableCursor
> > DEALLOCATE My_TableCursor
> >
> >
> > Phil.
> >
> > "Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
> > news:2F9C1F31-EBAE-4F11-B7B8-2E0B9E7540AF@microsoft.com...
> > > Bonjour,
> > >
> > > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > > Environnement fortement transactionnel avec forts volumes sur
certaines
> > > tables.
> > > Base de données unique, respectant les règles de normalité.
> > >
> > > Il semblerait que les procédures stockées créées via SQL Query
Builder,
> > > comme cela peut être le cas quand on recharge un script sauvegardé
dans un
> > > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > > l'intégralité des dépendances aux tables qu'elles utilisent.
> > >
> > > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
je
> > > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > > procédures stockées, table par table, et au matin, les performances
sont
> > > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
créées
> > via
> > > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > > externe). La simple ouverture de certaines procédures stockées-clefs
dans
> > > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> > demande
> > > de recompilation suffit à faire rentrer tout dans l'ordre...
> > >
> > > J'en déduis que cette absence de dépendances sur ces procédures
empêche
> > leur
> > > recompilation propre, et les statistiques fraîches de réindexation
> > > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > > freinent leur exécution.
> > >
> > > Je prends la moindre information.
> > > Merci.
> > >
> > > Jean-Yves AUGER
> > > DBA
> > > Limagrain Verneuil Holding
> >
> >
> >
Avez vous essayé l'ajout d'un "dbcc freeproccache" en fin de votre batch?
--
Cdlt,
FP
"Jean-Yves" wrote in message
news:
> Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
> recompilation les procédures dépendantes de mes 291 tables, ta méthode a
mis
> 1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
> même.
> Merci quand même.
>
> "Philippe [MS]" a écrit :
>
> > Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
de
> > mes clients.
> >
> > SET NOCOUNT ON
> >
> > DECLARE @CurObjectName nvarchar(200) -- Table or view name
> >
> > ----
> > -- Tables and Views recompilation
> > ----
> > DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> > SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> > name
> >
> > OPEN My_TableCursor
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > WHILE (@@fetch_status = 0)
> > BEGIN
> > EXEC( N'update statistics ' + @CurObjectName)
> > EXEC (N'exec sp_recompile ' + @CurObjectName)
> >
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > END
> > CLOSE My_TableCursor
> > DEALLOCATE My_TableCursor
> >
> >
> > Phil.
> >
> > "Jean-Yves" wrote in message
> > news:
> > > Bonjour,
> > >
> > > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > > Environnement fortement transactionnel avec forts volumes sur
certaines
> > > tables.
> > > Base de données unique, respectant les règles de normalité.
> > >
> > > Il semblerait que les procédures stockées créées via SQL Query
Builder,
> > > comme cela peut être le cas quand on recharge un script sauvegardé
dans un
> > > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > > l'intégralité des dépendances aux tables qu'elles utilisent.
> > >
> > > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
je
> > > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > > procédures stockées, table par table, et au matin, les performances
sont
> > > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
créées
> > via
> > > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > > externe). La simple ouverture de certaines procédures stockées-clefs
dans
> > > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> > demande
> > > de recompilation suffit à faire rentrer tout dans l'ordre...
> > >
> > > J'en déduis que cette absence de dépendances sur ces procédures
empêche
> > leur
> > > recompilation propre, et les statistiques fraîches de réindexation
> > > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > > freinent leur exécution.
> > >
> > > Je prends la moindre information.
> > > Merci.
> > >
> > > Jean-Yves AUGER
> > > DBA
> > > Limagrain Verneuil Holding
> >
> >
> >
Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
recompilation les procédures dépendantes de mes 291 tables, ta méthode a
1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
même.
Merci quand même.
"Philippe [MS]" a écrit :
> Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
> mes clients.
>
> SET NOCOUNT ON
>
> DECLARE @CurObjectName nvarchar(200) -- Table or view name
>
> ----
> -- Tables and Views recompilation
> ----
> DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> name
>
> OPEN My_TableCursor
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> WHILE (@@fetch_status = 0)
> BEGIN
> EXEC( N'update statistics ' + @CurObjectName)
> EXEC (N'exec sp_recompile ' + @CurObjectName)
>
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> END
> CLOSE My_TableCursor
> DEALLOCATE My_TableCursor
>
>
> Phil.
>
> "Jean-Yves" wrote in message
> news:
> > Bonjour,
> >
> > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > Environnement fortement transactionnel avec forts volumes sur
> > tables.
> > Base de données unique, respectant les règles de normalité.
> >
> > Il semblerait que les procédures stockées créées via SQL Query
> > comme cela peut être le cas quand on recharge un script sauvegardé
> > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > l'intégralité des dépendances aux tables qu'elles utilisent.
> >
> > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
> > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > procédures stockées, table par table, et au matin, les performances
> > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
> via
> > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > externe). La simple ouverture de certaines procédures stockées-clefs
> > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> demande
> > de recompilation suffit à faire rentrer tout dans l'ordre...
> >
> > J'en déduis que cette absence de dépendances sur ces procédures
> leur
> > recompilation propre, et les statistiques fraîches de réindexation
> > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > freinent leur exécution.
> >
> > Je prends la moindre information.
> > Merci.
> >
> > Jean-Yves AUGER
> > DBA
> > Limagrain Verneuil Holding
>
>
>
Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
recompilation les procédures dépendantes de mes 291 tables, ta méthode a
1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
même.
Merci quand même.
"Philippe [MS]" a écrit :
> Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
> mes clients.
>
> SET NOCOUNT ON
>
> DECLARE @CurObjectName nvarchar(200) -- Table or view name
>
> ----
> -- Tables and Views recompilation
> ----
> DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> name
>
> OPEN My_TableCursor
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> WHILE (@@fetch_status = 0)
> BEGIN
> EXEC( N'update statistics ' + @CurObjectName)
> EXEC (N'exec sp_recompile ' + @CurObjectName)
>
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> END
> CLOSE My_TableCursor
> DEALLOCATE My_TableCursor
>
>
> Phil.
>
> "Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
> news:2F9C1F31-EBAE-4F11-B7B8-2E0B9E7540AF@microsoft.com...
> > Bonjour,
> >
> > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > Environnement fortement transactionnel avec forts volumes sur
> > tables.
> > Base de données unique, respectant les règles de normalité.
> >
> > Il semblerait que les procédures stockées créées via SQL Query
> > comme cela peut être le cas quand on recharge un script sauvegardé
> > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > l'intégralité des dépendances aux tables qu'elles utilisent.
> >
> > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
> > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > procédures stockées, table par table, et au matin, les performances
> > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
> via
> > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > externe). La simple ouverture de certaines procédures stockées-clefs
> > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> demande
> > de recompilation suffit à faire rentrer tout dans l'ordre...
> >
> > J'en déduis que cette absence de dépendances sur ces procédures
> leur
> > recompilation propre, et les statistiques fraîches de réindexation
> > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > freinent leur exécution.
> >
> > Je prends la moindre information.
> > Merci.
> >
> > Jean-Yves AUGER
> > DBA
> > Limagrain Verneuil Holding
>
>
>
Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
recompilation les procédures dépendantes de mes 291 tables, ta méthode a
1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
même.
Merci quand même.
"Philippe [MS]" a écrit :
> Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
> mes clients.
>
> SET NOCOUNT ON
>
> DECLARE @CurObjectName nvarchar(200) -- Table or view name
>
> ----
> -- Tables and Views recompilation
> ----
> DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> name
>
> OPEN My_TableCursor
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> WHILE (@@fetch_status = 0)
> BEGIN
> EXEC( N'update statistics ' + @CurObjectName)
> EXEC (N'exec sp_recompile ' + @CurObjectName)
>
> FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> END
> CLOSE My_TableCursor
> DEALLOCATE My_TableCursor
>
>
> Phil.
>
> "Jean-Yves" wrote in message
> news:
> > Bonjour,
> >
> > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > Environnement fortement transactionnel avec forts volumes sur
> > tables.
> > Base de données unique, respectant les règles de normalité.
> >
> > Il semblerait que les procédures stockées créées via SQL Query
> > comme cela peut être le cas quand on recharge un script sauvegardé
> > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > l'intégralité des dépendances aux tables qu'elles utilisent.
> >
> > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
> > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > procédures stockées, table par table, et au matin, les performances
> > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
> via
> > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > externe). La simple ouverture de certaines procédures stockées-clefs
> > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> demande
> > de recompilation suffit à faire rentrer tout dans l'ordre...
> >
> > J'en déduis que cette absence de dépendances sur ces procédures
> leur
> > recompilation propre, et les statistiques fraîches de réindexation
> > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > freinent leur exécution.
> >
> > Je prends la moindre information.
> > Merci.
> >
> > Jean-Yves AUGER
> > DBA
> > Limagrain Verneuil Holding
>
>
>
Bonjour,
C'est lié au fait que je fais également un UPDATE STATISTICS sur les tables
!!!
Phil.
"Jean-Yves" wrote in message
news:
> Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
> recompilation les procédures dépendantes de mes 291 tables, ta méthode a
mis
> 1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
> même.
> Merci quand même.
>
> "Philippe [MS]" a écrit :
>
> > Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
de
> > mes clients.
> >
> > SET NOCOUNT ON
> >
> > DECLARE @CurObjectName nvarchar(200) -- Table or view name
> >
> > ----
> > -- Tables and Views recompilation
> > ----
> > DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> > SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> > name
> >
> > OPEN My_TableCursor
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > WHILE (@@fetch_status = 0)
> > BEGIN
> > EXEC( N'update statistics ' + @CurObjectName)
> > EXEC (N'exec sp_recompile ' + @CurObjectName)
> >
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > END
> > CLOSE My_TableCursor
> > DEALLOCATE My_TableCursor
> >
> >
> > Phil.
> >
> > "Jean-Yves" wrote in message
> > news:
> > > Bonjour,
> > >
> > > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > > Environnement fortement transactionnel avec forts volumes sur
certaines
> > > tables.
> > > Base de données unique, respectant les règles de normalité.
> > >
> > > Il semblerait que les procédures stockées créées via SQL Query
Builder,
> > > comme cela peut être le cas quand on recharge un script sauvegardé
dans un
> > > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > > l'intégralité des dépendances aux tables qu'elles utilisent.
> > >
> > > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
je
> > > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > > procédures stockées, table par table, et au matin, les performances
sont
> > > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
créées
> > via
> > > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > > externe). La simple ouverture de certaines procédures stockées-clefs
dans
> > > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> > demande
> > > de recompilation suffit à faire rentrer tout dans l'ordre...
> > >
> > > J'en déduis que cette absence de dépendances sur ces procédures
empêche
> > leur
> > > recompilation propre, et les statistiques fraîches de réindexation
> > > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > > freinent leur exécution.
> > >
> > > Je prends la moindre information.
> > > Merci.
> > >
> > > Jean-Yves AUGER
> > > DBA
> > > Limagrain Verneuil Holding
> >
> >
> >
Bonjour,
C'est lié au fait que je fais également un UPDATE STATISTICS sur les tables
!!!
Phil.
"Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
news:2509319C-DCD1-4CF9-9C1B-416D4BF88C13@microsoft.com...
> Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
> recompilation les procédures dépendantes de mes 291 tables, ta méthode a
mis
> 1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
> même.
> Merci quand même.
>
> "Philippe [MS]" a écrit :
>
> > Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
de
> > mes clients.
> >
> > SET NOCOUNT ON
> >
> > DECLARE @CurObjectName nvarchar(200) -- Table or view name
> >
> > ----
> > -- Tables and Views recompilation
> > ----
> > DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> > SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> > name
> >
> > OPEN My_TableCursor
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > WHILE (@@fetch_status = 0)
> > BEGIN
> > EXEC( N'update statistics ' + @CurObjectName)
> > EXEC (N'exec sp_recompile ' + @CurObjectName)
> >
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > END
> > CLOSE My_TableCursor
> > DEALLOCATE My_TableCursor
> >
> >
> > Phil.
> >
> > "Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
> > news:2F9C1F31-EBAE-4F11-B7B8-2E0B9E7540AF@microsoft.com...
> > > Bonjour,
> > >
> > > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > > Environnement fortement transactionnel avec forts volumes sur
certaines
> > > tables.
> > > Base de données unique, respectant les règles de normalité.
> > >
> > > Il semblerait que les procédures stockées créées via SQL Query
Builder,
> > > comme cela peut être le cas quand on recharge un script sauvegardé
dans un
> > > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > > l'intégralité des dépendances aux tables qu'elles utilisent.
> > >
> > > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
je
> > > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > > procédures stockées, table par table, et au matin, les performances
sont
> > > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
créées
> > via
> > > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > > externe). La simple ouverture de certaines procédures stockées-clefs
dans
> > > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> > demande
> > > de recompilation suffit à faire rentrer tout dans l'ordre...
> > >
> > > J'en déduis que cette absence de dépendances sur ces procédures
empêche
> > leur
> > > recompilation propre, et les statistiques fraîches de réindexation
> > > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > > freinent leur exécution.
> > >
> > > Je prends la moindre information.
> > > Merci.
> > >
> > > Jean-Yves AUGER
> > > DBA
> > > Limagrain Verneuil Holding
> >
> >
> >
Bonjour,
C'est lié au fait que je fais également un UPDATE STATISTICS sur les tables
!!!
Phil.
"Jean-Yves" wrote in message
news:
> Quelques nouvelles nocturnes : au lieu des 19 s habituelles pour marquer à
> recompilation les procédures dépendantes de mes 291 tables, ta méthode a
mis
> 1mn 33s. Je ne sais pas encore à quoi c'est dû, mais le résultat reste le
> même.
> Merci quand même.
>
> "Philippe [MS]" a écrit :
>
> > Moi j'utilise cela mais j'avais constaté un phénomène équivalent chez un
de
> > mes clients.
> >
> > SET NOCOUNT ON
> >
> > DECLARE @CurObjectName nvarchar(200) -- Table or view name
> >
> > ----
> > -- Tables and Views recompilation
> > ----
> > DECLARE My_TableCursor CURSOR FAST_FORWARD FOR
> > SELECT name FROM SysObjects WHERE xtype = 'U' AND status >= 0 ORDER BY
> > name
> >
> > OPEN My_TableCursor
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > WHILE (@@fetch_status = 0)
> > BEGIN
> > EXEC( N'update statistics ' + @CurObjectName)
> > EXEC (N'exec sp_recompile ' + @CurObjectName)
> >
> > FETCH NEXT FROM My_TableCursor INTO @CurObjectName
> > END
> > CLOSE My_TableCursor
> > DEALLOCATE My_TableCursor
> >
> >
> > Phil.
> >
> > "Jean-Yves" wrote in message
> > news:
> > > Bonjour,
> > >
> > > SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
> > > Environnement fortement transactionnel avec forts volumes sur
certaines
> > > tables.
> > > Base de données unique, respectant les règles de normalité.
> > >
> > > Il semblerait que les procédures stockées créées via SQL Query
Builder,
> > > comme cela peut être le cas quand on recharge un script sauvegardé
dans un
> > > fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
> > > l'intégralité des dépendances aux tables qu'elles utilisent.
> > >
> > > Résultat : dans la nuit, après la recréation de mes (nombreux) index,
je
> > > demande (via sp_recompile) le marquage à recompilation de toutes mes
> > > procédures stockées, table par table, et au matin, les performances
sont
> > > CATASTROPHIQUES pour certaines procédures, qui visiblement ont été
créées
> > via
> > > SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
> > > externe). La simple ouverture de certaines procédures stockées-clefs
dans
> > > SEM, un ajout puis une suppession d'un caractère n'importe où et une
> > demande
> > > de recompilation suffit à faire rentrer tout dans l'ordre...
> > >
> > > J'en déduis que cette absence de dépendances sur ces procédures
empêche
> > leur
> > > recompilation propre, et les statistiques fraîches de réindexation
> > > déclenchent des recompilations parasites avec un contexte bâtard, qui
> > > freinent leur exécution.
> > >
> > > Je prends la moindre information.
> > > Merci.
> > >
> > > Jean-Yves AUGER
> > > DBA
> > > Limagrain Verneuil Holding
> >
> >
> >
Bonjour,
SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
Environnement fortement transactionnel avec forts volumes sur certaines
tables.
Base de données unique, respectant les règles de normalité.
Il semblerait que les procédures stockées créées via SQL Query Builder,
comme cela peut être le cas quand on recharge un script sauvegardé dans un
fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
l'intégralité des dépendances aux tables qu'elles utilisent.
Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
demande (via sp_recompile) le marquage à recompilation de toutes mes
procédures stockées, table par table, et au matin, les performances sont
CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées via
SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
externe). La simple ouverture de certaines procédures stockées-clefs dans
SEM, un ajout puis une suppession d'un caractère n'importe où et une demande
de recompilation suffit à faire rentrer tout dans l'ordre...
J'en déduis que cette absence de dépendances sur ces procédures empêche leur
recompilation propre, et les statistiques fraîches de réindexation
déclenchent des recompilations parasites avec un contexte bâtard, qui
freinent leur exécution.
Je prends la moindre information.
Merci.
Jean-Yves AUGER
DBA
Limagrain Verneuil Holding
Bonjour,
SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
Environnement fortement transactionnel avec forts volumes sur certaines
tables.
Base de données unique, respectant les règles de normalité.
Il semblerait que les procédures stockées créées via SQL Query Builder,
comme cela peut être le cas quand on recharge un script sauvegardé dans un
fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
l'intégralité des dépendances aux tables qu'elles utilisent.
Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
demande (via sp_recompile) le marquage à recompilation de toutes mes
procédures stockées, table par table, et au matin, les performances sont
CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées via
SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
externe). La simple ouverture de certaines procédures stockées-clefs dans
SEM, un ajout puis une suppession d'un caractère n'importe où et une demande
de recompilation suffit à faire rentrer tout dans l'ordre...
J'en déduis que cette absence de dépendances sur ces procédures empêche leur
recompilation propre, et les statistiques fraîches de réindexation
déclenchent des recompilations parasites avec un contexte bâtard, qui
freinent leur exécution.
Je prends la moindre information.
Merci.
Jean-Yves AUGER
DBA
Limagrain Verneuil Holding
Bonjour,
SQLServer 2000 SP3a / Windows Server 2003 / 5.5 Go RAM
Environnement fortement transactionnel avec forts volumes sur certaines
tables.
Base de données unique, respectant les règles de normalité.
Il semblerait que les procédures stockées créées via SQL Query Builder,
comme cela peut être le cas quand on recharge un script sauvegardé dans un
fichier texte dans la fenêtre avant de le compiler, n'inscrivent pas
l'intégralité des dépendances aux tables qu'elles utilisent.
Résultat : dans la nuit, après la recréation de mes (nombreux) index, je
demande (via sp_recompile) le marquage à recompilation de toutes mes
procédures stockées, table par table, et au matin, les performances sont
CATASTROPHIQUES pour certaines procédures, qui visiblement ont été créées via
SQL QB et non SEM comme 80% des autres (intégration de sous-traitance
externe). La simple ouverture de certaines procédures stockées-clefs dans
SEM, un ajout puis une suppession d'un caractère n'importe où et une demande
de recompilation suffit à faire rentrer tout dans l'ordre...
J'en déduis que cette absence de dépendances sur ces procédures empêche leur
recompilation propre, et les statistiques fraîches de réindexation
déclenchent des recompilations parasites avec un contexte bâtard, qui
freinent leur exécution.
Je prends la moindre information.
Merci.
Jean-Yves AUGER
DBA
Limagrain Verneuil Holding