bonjour,
je me trouve devant un petit problème.résumé bref de la situation, plusieurs
plate installé sous SQL 2005, chaque nuit un traitement de maintenance est
exsecuté par le biais de SQL Agent, pour reindexe ou reorganisé les index
effectué une mise à jour partiel des stats sur les colonnes non indexe et une
sauvegarde de la base.
le traitement s'execute sans problème sur plusieurs plate forme, sauf
aujourd'hui sur une plate forme.
Anomalie constaté sur la mise à jour des stats, message ci-dessous:
Message 601, gravité 12, état 1, ligne 1 : Impossible de poursuivre
l'analyse avec NOLOCK car les données ont été déplacées. [SQLSTATE 42000]
j'avais déjà constaté sous SQL2000 ce type d'erreur dans d'autre traitement
qui pouvais ce justifié. or ici je ne vois pas comment résoudre cet incident,
qui n'est malheureusement pas reproductible.
la procédure ne force aucun mode isolation de transaction, aucune option
with (nolock) utilisé, aucune transaction. seul problème possible pacours
d'un curseur sans typage (fast_forward ou tout autre typage) mais je doute
que le problème vienne de là, ci-dessous un exemple simplifié du curseur
parcouru:
declare @strTable sysname
set @strTable = '%'
declare us_table_colonne cursor for
select name, ' UPDATE STATISTICS ' + name + ' RESAMPLE, COLUMNS ' + case
when options = '' then '' else ', '+ options end
from (
select name = object_name(sta.object_id)
, options = case when sta.no_recompute = 0 then '' else 'NORECOMPUTE' end
, row = row_number() over( partition by sta.object_id order by
sta.object_id, sta.stats_id )
from sys.stats as sta
inner join (
-- liste des tables hors tables du filegroup TRACE
select distinct object_id = id from sys.sysindexes as ind
inner join sys.filegroups as grp on grp.data_space_id = ind.groupid
where grp.name != 'TRACE'
) as tab on tab.object_id = sta.object_id
where indexproperty(sta.object_id,sta.name,'IsStatistics') = 1
and objectproperty(sta.object_id,'IsMsShipped') = 0
and objectproperty(sta.object_id,'IsTable') = 1
and object_name(sta.object_id) like @strTables
) as grp
where grp.row = 1
order by 1
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Leon
"Leon" a écrit :
bonjour, je me trouve devant un petit problème.résumé bref de la situation, plusieurs plate installé sous SQL 2005, chaque nuit un traitement de maintenance est exsecuté par le biais de SQL Agent, pour reindexe ou reorganisé les index effectué une mise à jour partiel des stats sur les colonnes non indexe et une sauvegarde de la base. le traitement s'execute sans problème sur plusieurs plate forme, sauf aujourd'hui sur une plate forme. Anomalie constaté sur la mise à jour des stats, message ci-dessous: Message 601, gravité 12, état 1, ligne 1 : Impossible de poursuivre l'analyse avec NOLOCK car les données ont été déplacées. [SQLSTATE 42000]
j'avais déjà constaté sous SQL2000 ce type d'erreur dans d'autre traitement qui pouvais ce justifié. or ici je ne vois pas comment résoudre cet incident, qui n'est malheureusement pas reproductible.
la procédure ne force aucun mode isolation de transaction, aucune option with (nolock) utilisé, aucune transaction. seul problème possible pacours d'un curseur sans typage (fast_forward ou tout autre typage) mais je doute que le problème vienne de là, ci-dessous un exemple simplifié du curseur parcouru:
declare @strTable sysname set @strTable = '%' declare us_table_colonne cursor for select name, ' UPDATE STATISTICS ' + name + ' RESAMPLE, COLUMNS ' + case when options = '' then '' else ', '+ options end from ( select name = object_name(sta.object_id) , options = case when sta.no_recompute = 0 then '' else 'NORECOMPUTE' end , row = row_number() over( partition by sta.object_id order by sta.object_id, sta.stats_id ) from sys.stats as sta inner join ( -- liste des tables hors tables du filegroup TRACE select distinct object_id = id from sys.sysindexes as ind inner join sys.filegroups as grp on grp.data_space_id = ind.groupid where grp.name != 'TRACE' ) as tab on tab.object_id = sta.object_id where indexproperty(sta.object_id,sta.name,'IsStatistics') = 1 and objectproperty(sta.object_id,'IsMsShipped') = 0 and objectproperty(sta.object_id,'IsTable') = 1 and object_name(sta.object_id) like @strTables ) as grp where grp.row = 1 order by 1
si vous avez une idée je suis preneur.
merci.
Problème hardware identifié, problème I/O disque.
"Leon" a écrit :
bonjour,
je me trouve devant un petit problème.résumé bref de la situation, plusieurs
plate installé sous SQL 2005, chaque nuit un traitement de maintenance est
exsecuté par le biais de SQL Agent, pour reindexe ou reorganisé les index
effectué une mise à jour partiel des stats sur les colonnes non indexe et une
sauvegarde de la base.
le traitement s'execute sans problème sur plusieurs plate forme, sauf
aujourd'hui sur une plate forme.
Anomalie constaté sur la mise à jour des stats, message ci-dessous:
Message 601, gravité 12, état 1, ligne 1 : Impossible de poursuivre
l'analyse avec NOLOCK car les données ont été déplacées. [SQLSTATE 42000]
j'avais déjà constaté sous SQL2000 ce type d'erreur dans d'autre traitement
qui pouvais ce justifié. or ici je ne vois pas comment résoudre cet incident,
qui n'est malheureusement pas reproductible.
la procédure ne force aucun mode isolation de transaction, aucune option
with (nolock) utilisé, aucune transaction. seul problème possible pacours
d'un curseur sans typage (fast_forward ou tout autre typage) mais je doute
que le problème vienne de là, ci-dessous un exemple simplifié du curseur
parcouru:
declare @strTable sysname
set @strTable = '%'
declare us_table_colonne cursor for
select name, ' UPDATE STATISTICS ' + name + ' RESAMPLE, COLUMNS ' + case
when options = '' then '' else ', '+ options end
from (
select name = object_name(sta.object_id)
, options = case when sta.no_recompute = 0 then '' else 'NORECOMPUTE' end
, row = row_number() over( partition by sta.object_id order by
sta.object_id, sta.stats_id )
from sys.stats as sta
inner join (
-- liste des tables hors tables du filegroup TRACE
select distinct object_id = id from sys.sysindexes as ind
inner join sys.filegroups as grp on grp.data_space_id = ind.groupid
where grp.name != 'TRACE'
) as tab on tab.object_id = sta.object_id
where indexproperty(sta.object_id,sta.name,'IsStatistics') = 1
and objectproperty(sta.object_id,'IsMsShipped') = 0
and objectproperty(sta.object_id,'IsTable') = 1
and object_name(sta.object_id) like @strTables
) as grp
where grp.row = 1
order by 1
bonjour, je me trouve devant un petit problème.résumé bref de la situation, plusieurs plate installé sous SQL 2005, chaque nuit un traitement de maintenance est exsecuté par le biais de SQL Agent, pour reindexe ou reorganisé les index effectué une mise à jour partiel des stats sur les colonnes non indexe et une sauvegarde de la base. le traitement s'execute sans problème sur plusieurs plate forme, sauf aujourd'hui sur une plate forme. Anomalie constaté sur la mise à jour des stats, message ci-dessous: Message 601, gravité 12, état 1, ligne 1 : Impossible de poursuivre l'analyse avec NOLOCK car les données ont été déplacées. [SQLSTATE 42000]
j'avais déjà constaté sous SQL2000 ce type d'erreur dans d'autre traitement qui pouvais ce justifié. or ici je ne vois pas comment résoudre cet incident, qui n'est malheureusement pas reproductible.
la procédure ne force aucun mode isolation de transaction, aucune option with (nolock) utilisé, aucune transaction. seul problème possible pacours d'un curseur sans typage (fast_forward ou tout autre typage) mais je doute que le problème vienne de là, ci-dessous un exemple simplifié du curseur parcouru:
declare @strTable sysname set @strTable = '%' declare us_table_colonne cursor for select name, ' UPDATE STATISTICS ' + name + ' RESAMPLE, COLUMNS ' + case when options = '' then '' else ', '+ options end from ( select name = object_name(sta.object_id) , options = case when sta.no_recompute = 0 then '' else 'NORECOMPUTE' end , row = row_number() over( partition by sta.object_id order by sta.object_id, sta.stats_id ) from sys.stats as sta inner join ( -- liste des tables hors tables du filegroup TRACE select distinct object_id = id from sys.sysindexes as ind inner join sys.filegroups as grp on grp.data_space_id = ind.groupid where grp.name != 'TRACE' ) as tab on tab.object_id = sta.object_id where indexproperty(sta.object_id,sta.name,'IsStatistics') = 1 and objectproperty(sta.object_id,'IsMsShipped') = 0 and objectproperty(sta.object_id,'IsTable') = 1 and object_name(sta.object_id) like @strTables ) as grp where grp.row = 1 order by 1
si vous avez une idée je suis preneur.
merci.
Problème hardware identifié, problème I/O disque.
zoltix
Leon a écrit :
"Leon" a écrit :
bonjour, je me trouve devant un petit problème.résumé bref de la situation, plusieurs plate installé sous SQL 2005, chaque nuit un traitement de maintenance est exsecuté par le biais de SQL Agent, pour reindexe ou reorganisé les index effectué une mise à jour partiel des stats sur les colonnes non indexe et une sauvegarde de la base. le traitement s'execute sans problème sur plusieurs plate forme, sauf aujourd'hui sur une plate forme. Anomalie constaté sur la mise à jour des stats, message ci-dessous: Message 601, gravité 12, état 1, ligne 1 : Impossible de poursuivre l'analyse avec NOLOCK car les données ont été déplacées. [SQLSTATE 42000]
j'avais déjà constaté sous SQL2000 ce type d'erreur dans d'autre traitement qui pouvais ce justifié. or ici je ne vois pas comment résoudre cet incident, qui n'est malheureusement pas reproductible.
la procédure ne force aucun mode isolation de transaction, aucune option with (nolock) utilisé, aucune transaction. seul problème possible pacours d'un curseur sans typage (fast_forward ou tout autre typage) mais je doute que le problème vienne de là, ci-dessous un exemple simplifié du curseur parcouru:
declare @strTable sysname set @strTable = '%' declare us_table_colonne cursor for select name, ' UPDATE STATISTICS ' + name + ' RESAMPLE, COLUMNS ' + case when options = '' then '' else ', '+ options end from ( select name = object_name(sta.object_id) , options = case when sta.no_recompute = 0 then '' else 'NORECOMPUTE' end , row = row_number() over( partition by sta.object_id order by sta.object_id, sta.stats_id ) from sys.stats as sta inner join ( -- liste des tables hors tables du filegroup TRACE select distinct object_id = id from sys.sysindexes as ind inner join sys.filegroups as grp on grp.data_space_id = ind.groupid where grp.name != 'TRACE' ) as tab on tab.object_id = sta.object_id where indexproperty(sta.object_id,sta.name,'IsStatistics') = 1 and objectproperty(sta.object_id,'IsMsShipped') = 0 and objectproperty(sta.object_id,'IsTable') = 1 and object_name(sta.object_id) like @strTables ) as grp where grp.row = 1 order by 1
si vous avez une idée je suis preneur.
merci.
Problème hardware identifié, problème I/O disque.
Est ce que tes disques sont en Raid? (Raid 1 5 1+0) ?
Leon a écrit :
"Leon" a écrit :
bonjour,
je me trouve devant un petit problème.résumé bref de la situation, plusieurs
plate installé sous SQL 2005, chaque nuit un traitement de maintenance est
exsecuté par le biais de SQL Agent, pour reindexe ou reorganisé les index
effectué une mise à jour partiel des stats sur les colonnes non indexe et une
sauvegarde de la base.
le traitement s'execute sans problème sur plusieurs plate forme, sauf
aujourd'hui sur une plate forme.
Anomalie constaté sur la mise à jour des stats, message ci-dessous:
Message 601, gravité 12, état 1, ligne 1 : Impossible de poursuivre
l'analyse avec NOLOCK car les données ont été déplacées. [SQLSTATE 42000]
j'avais déjà constaté sous SQL2000 ce type d'erreur dans d'autre traitement
qui pouvais ce justifié. or ici je ne vois pas comment résoudre cet incident,
qui n'est malheureusement pas reproductible.
la procédure ne force aucun mode isolation de transaction, aucune option
with (nolock) utilisé, aucune transaction. seul problème possible pacours
d'un curseur sans typage (fast_forward ou tout autre typage) mais je doute
que le problème vienne de là, ci-dessous un exemple simplifié du curseur
parcouru:
declare @strTable sysname
set @strTable = '%'
declare us_table_colonne cursor for
select name, ' UPDATE STATISTICS ' + name + ' RESAMPLE, COLUMNS ' + case
when options = '' then '' else ', '+ options end
from (
select name = object_name(sta.object_id)
, options = case when sta.no_recompute = 0 then '' else 'NORECOMPUTE' end
, row = row_number() over( partition by sta.object_id order by
sta.object_id, sta.stats_id )
from sys.stats as sta
inner join (
-- liste des tables hors tables du filegroup TRACE
select distinct object_id = id from sys.sysindexes as ind
inner join sys.filegroups as grp on grp.data_space_id = ind.groupid
where grp.name != 'TRACE'
) as tab on tab.object_id = sta.object_id
where indexproperty(sta.object_id,sta.name,'IsStatistics') = 1
and objectproperty(sta.object_id,'IsMsShipped') = 0
and objectproperty(sta.object_id,'IsTable') = 1
and object_name(sta.object_id) like @strTables
) as grp
where grp.row = 1
order by 1
si vous avez une idée je suis preneur.
merci.
Problème hardware identifié, problème I/O disque.
Est ce que tes disques sont en Raid? (Raid 1 5 1+0) ?
bonjour, je me trouve devant un petit problème.résumé bref de la situation, plusieurs plate installé sous SQL 2005, chaque nuit un traitement de maintenance est exsecuté par le biais de SQL Agent, pour reindexe ou reorganisé les index effectué une mise à jour partiel des stats sur les colonnes non indexe et une sauvegarde de la base. le traitement s'execute sans problème sur plusieurs plate forme, sauf aujourd'hui sur une plate forme. Anomalie constaté sur la mise à jour des stats, message ci-dessous: Message 601, gravité 12, état 1, ligne 1 : Impossible de poursuivre l'analyse avec NOLOCK car les données ont été déplacées. [SQLSTATE 42000]
j'avais déjà constaté sous SQL2000 ce type d'erreur dans d'autre traitement qui pouvais ce justifié. or ici je ne vois pas comment résoudre cet incident, qui n'est malheureusement pas reproductible.
la procédure ne force aucun mode isolation de transaction, aucune option with (nolock) utilisé, aucune transaction. seul problème possible pacours d'un curseur sans typage (fast_forward ou tout autre typage) mais je doute que le problème vienne de là, ci-dessous un exemple simplifié du curseur parcouru:
declare @strTable sysname set @strTable = '%' declare us_table_colonne cursor for select name, ' UPDATE STATISTICS ' + name + ' RESAMPLE, COLUMNS ' + case when options = '' then '' else ', '+ options end from ( select name = object_name(sta.object_id) , options = case when sta.no_recompute = 0 then '' else 'NORECOMPUTE' end , row = row_number() over( partition by sta.object_id order by sta.object_id, sta.stats_id ) from sys.stats as sta inner join ( -- liste des tables hors tables du filegroup TRACE select distinct object_id = id from sys.sysindexes as ind inner join sys.filegroups as grp on grp.data_space_id = ind.groupid where grp.name != 'TRACE' ) as tab on tab.object_id = sta.object_id where indexproperty(sta.object_id,sta.name,'IsStatistics') = 1 and objectproperty(sta.object_id,'IsMsShipped') = 0 and objectproperty(sta.object_id,'IsTable') = 1 and object_name(sta.object_id) like @strTables ) as grp where grp.row = 1 order by 1
si vous avez une idée je suis preneur.
merci.
Problème hardware identifié, problème I/O disque.
Est ce que tes disques sont en Raid? (Raid 1 5 1+0) ?
Leon
"zoltix" a écrit :
Leon a écrit : > "Leon" a écrit : > >> bonjour, >> je me trouve devant un petit problème.résumé bref de la situation, plusieurs >> plate installé sous SQL 2005, chaque nuit un traitement de maintenance est >> exsecuté par le biais de SQL Agent, pour reindexe ou reorganisé les index >> effectué une mise à jour partiel des stats sur les colonnes non indexe et une >> sauvegarde de la base. >> le traitement s'execute sans problème sur plusieurs plate forme, sauf >> aujourd'hui sur une plate forme. >> Anomalie constaté sur la mise à jour des stats, message ci-dessous: >> Message 601, gravité 12, état 1, ligne 1 : Impossible de poursuivre >> l'analyse avec NOLOCK car les données ont été déplacées. [SQLSTATE 42000] >> >> j'avais déjà constaté sous SQL2000 ce type d'erreur dans d'autre traitement >> qui pouvais ce justifié. or ici je ne vois pas comment résoudre cet incident, >> qui n'est malheureusement pas reproductible. >> >> la procédure ne force aucun mode isolation de transaction, aucune option >> with (nolock) utilisé, aucune transaction. seul problème possible pacours >> d'un curseur sans typage (fast_forward ou tout autre typage) mais je doute >> que le problème vienne de là, ci-dessous un exemple simplifié du curseur >> parcouru: >> >> declare @strTable sysname >> set @strTable = '%' >> declare us_table_colonne cursor for >> select name, ' UPDATE STATISTICS ' + name + ' RESAMPLE, COLUMNS ' + case >> when options = '' then '' else ', '+ options end >> from ( >> select name = object_name(sta.object_id) >> , options = case when sta.no_recompute = 0 then '' else 'NORECOMPUTE' end >> , row = row_number() over( partition by sta.object_id order by >> sta.object_id, sta.stats_id ) >> from sys.stats as sta >> inner join ( >> -- liste des tables hors tables du filegroup TRACE >> select distinct object_id = id from sys.sysindexes as ind >> inner join sys.filegroups as grp on grp.data_space_id = ind.groupid >> where grp.name != 'TRACE' >> ) as tab on tab.object_id = sta.object_id >> where indexproperty(sta.object_id,sta.name,'IsStatistics') = 1 >> and objectproperty(sta.object_id,'IsMsShipped') = 0 >> and objectproperty(sta.object_id,'IsTable') = 1 >> and object_name(sta.object_id) like @strTables >> ) as grp >> where grp.row = 1 >> order by 1 >> >> >> si vous avez une idée je suis preneur. >> >> merci. >> > > Problème hardware identifié, problème I/O disque. > Est ce que tes disques sont en Raid? (Raid 1 5 1+0) ?
Raid 5 sur une baie SAN (environnement non production ), Prevision environnement production Raid 1 sur même baie, mais impossible pour l'instant de testé sur sur environnement de production.
"zoltix" a écrit :
Leon a écrit :
> "Leon" a écrit :
>
>> bonjour,
>> je me trouve devant un petit problème.résumé bref de la situation, plusieurs
>> plate installé sous SQL 2005, chaque nuit un traitement de maintenance est
>> exsecuté par le biais de SQL Agent, pour reindexe ou reorganisé les index
>> effectué une mise à jour partiel des stats sur les colonnes non indexe et une
>> sauvegarde de la base.
>> le traitement s'execute sans problème sur plusieurs plate forme, sauf
>> aujourd'hui sur une plate forme.
>> Anomalie constaté sur la mise à jour des stats, message ci-dessous:
>> Message 601, gravité 12, état 1, ligne 1 : Impossible de poursuivre
>> l'analyse avec NOLOCK car les données ont été déplacées. [SQLSTATE 42000]
>>
>> j'avais déjà constaté sous SQL2000 ce type d'erreur dans d'autre traitement
>> qui pouvais ce justifié. or ici je ne vois pas comment résoudre cet incident,
>> qui n'est malheureusement pas reproductible.
>>
>> la procédure ne force aucun mode isolation de transaction, aucune option
>> with (nolock) utilisé, aucune transaction. seul problème possible pacours
>> d'un curseur sans typage (fast_forward ou tout autre typage) mais je doute
>> que le problème vienne de là, ci-dessous un exemple simplifié du curseur
>> parcouru:
>>
>> declare @strTable sysname
>> set @strTable = '%'
>> declare us_table_colonne cursor for
>> select name, ' UPDATE STATISTICS ' + name + ' RESAMPLE, COLUMNS ' + case
>> when options = '' then '' else ', '+ options end
>> from (
>> select name = object_name(sta.object_id)
>> , options = case when sta.no_recompute = 0 then '' else 'NORECOMPUTE' end
>> , row = row_number() over( partition by sta.object_id order by
>> sta.object_id, sta.stats_id )
>> from sys.stats as sta
>> inner join (
>> -- liste des tables hors tables du filegroup TRACE
>> select distinct object_id = id from sys.sysindexes as ind
>> inner join sys.filegroups as grp on grp.data_space_id = ind.groupid
>> where grp.name != 'TRACE'
>> ) as tab on tab.object_id = sta.object_id
>> where indexproperty(sta.object_id,sta.name,'IsStatistics') = 1
>> and objectproperty(sta.object_id,'IsMsShipped') = 0
>> and objectproperty(sta.object_id,'IsTable') = 1
>> and object_name(sta.object_id) like @strTables
>> ) as grp
>> where grp.row = 1
>> order by 1
>>
>>
>> si vous avez une idée je suis preneur.
>>
>> merci.
>>
>
> Problème hardware identifié, problème I/O disque.
>
Est ce que tes disques sont en Raid? (Raid 1 5 1+0) ?
Raid 5 sur une baie SAN (environnement non production ), Prevision
environnement production Raid 1 sur même baie, mais impossible pour l'instant
de testé sur
sur environnement de production.
Leon a écrit : > "Leon" a écrit : > >> bonjour, >> je me trouve devant un petit problème.résumé bref de la situation, plusieurs >> plate installé sous SQL 2005, chaque nuit un traitement de maintenance est >> exsecuté par le biais de SQL Agent, pour reindexe ou reorganisé les index >> effectué une mise à jour partiel des stats sur les colonnes non indexe et une >> sauvegarde de la base. >> le traitement s'execute sans problème sur plusieurs plate forme, sauf >> aujourd'hui sur une plate forme. >> Anomalie constaté sur la mise à jour des stats, message ci-dessous: >> Message 601, gravité 12, état 1, ligne 1 : Impossible de poursuivre >> l'analyse avec NOLOCK car les données ont été déplacées. [SQLSTATE 42000] >> >> j'avais déjà constaté sous SQL2000 ce type d'erreur dans d'autre traitement >> qui pouvais ce justifié. or ici je ne vois pas comment résoudre cet incident, >> qui n'est malheureusement pas reproductible. >> >> la procédure ne force aucun mode isolation de transaction, aucune option >> with (nolock) utilisé, aucune transaction. seul problème possible pacours >> d'un curseur sans typage (fast_forward ou tout autre typage) mais je doute >> que le problème vienne de là, ci-dessous un exemple simplifié du curseur >> parcouru: >> >> declare @strTable sysname >> set @strTable = '%' >> declare us_table_colonne cursor for >> select name, ' UPDATE STATISTICS ' + name + ' RESAMPLE, COLUMNS ' + case >> when options = '' then '' else ', '+ options end >> from ( >> select name = object_name(sta.object_id) >> , options = case when sta.no_recompute = 0 then '' else 'NORECOMPUTE' end >> , row = row_number() over( partition by sta.object_id order by >> sta.object_id, sta.stats_id ) >> from sys.stats as sta >> inner join ( >> -- liste des tables hors tables du filegroup TRACE >> select distinct object_id = id from sys.sysindexes as ind >> inner join sys.filegroups as grp on grp.data_space_id = ind.groupid >> where grp.name != 'TRACE' >> ) as tab on tab.object_id = sta.object_id >> where indexproperty(sta.object_id,sta.name,'IsStatistics') = 1 >> and objectproperty(sta.object_id,'IsMsShipped') = 0 >> and objectproperty(sta.object_id,'IsTable') = 1 >> and object_name(sta.object_id) like @strTables >> ) as grp >> where grp.row = 1 >> order by 1 >> >> >> si vous avez une idée je suis preneur. >> >> merci. >> > > Problème hardware identifié, problème I/O disque. > Est ce que tes disques sont en Raid? (Raid 1 5 1+0) ?
Raid 5 sur une baie SAN (environnement non production ), Prevision environnement production Raid 1 sur même baie, mais impossible pour l'instant de testé sur sur environnement de production.
