[SQL2K] Tabel corrupt?

[P_de_B]

Wij hebben hier een SQL Server 2000 database, en plotseling kon ik ineens van een tabel niet meer een bepaalde maand selecten.

Ik deed een query als

code:

SELECT * FROM tabel WHERE Maand = 1 
AND Nr NOT IN (SELECT Nr FROM Tabel WHERE Maand = 2)

Deze query gaf geen resultaat, terwijl er voldoende rijen waren die aan de criteria voldeden. Alle andere combinaties van maanden geven wel het gewenste resultaat.

Een select op

code:

SELECT Nr FROM Tabel WHERE Maand = 2

resulteert in een query die minuten loopt, als ik op cancel query klik zie ik wel een gedeelte van de rijen. Ze zitten er dus wel in! Als ik een andere maand kies krijg ik in een seconde de gewenste rijen te zien.

Ik heb een backup gemaakt en deze teruggelezen op mijn eigen laptop, maar ook daar trad het probleem op.

Vervolgens heb ik alle gegevens uit de tabel naar een nieuwe gekopieerd, de oorspronkelijke tabel gedropt en alles uit de nieuwe weer naar de oorspronkelijke tabel gekopieerd en het probleem was verholpen!

1) Weet iemand of dit een bekend probleem is, heeft iemand dit eerder gehad?

2) Omdat de backup hetzelfde gedrag vertoont ben ik wel nieuwsgierig of ik iets aan de tabel kan 'zien' wat bovenstaand gedrag vertoont. Een commando dat de 'integriteit' van een tabel controleert bijvoorbeeld.

3) Is er iets dat ik als onderhoud kan verrichten zodat deze problemen niet weer voorkomen?

[P_de_B]

*schop*

[Gé Brander]

Volgens mij kan dit met corrupte indexen te maken hebben, of je moet een of ander DBCC commando uit kunnen voeren om dit te herstellen. Weet zo snel niet welke.

[Verwijderd]

Als je de subquery uitvoert zie je een gedeelte van de regels. In je hoofdquery zeg je 'where NOT in'. Die hoofdquery selecteert dus allen de regels waarvan het nummber NIET in de subquery staat.
Geef anders ns n paar voorbeeldrecords.

[P_de_B]

Als ik een DBCC CHECKTABLE doe krijg ik gewoon een opsomming van het aantal rijen en pages. Verder niets.

Ik ben het met je eens dat een index vermoedelijk corrupt zal zijn, maar voordat ik een DBCC DBREINDEX of zo doe zou ik graag weten of ik een melding kan krijgen dat een bepaalde index defect is. Ik kan de periodiek controleren of er iets verkeerd is.

Ik baal echt ontzettend dat zoiets gebeuren kan, en zou het graag voorkomen.

^{bijna € 100.000 te weinig aan invoerrechten betaald}

[P_de_B]

Verwijderd schreef op 03 maart 2004 @ 15:20:
Als je de subquery uitvoert zie je een gedeelte van de regels. In je hoofdquery zeg je 'where NOT in'. Die hoofdquery selecteert dus allen de regels waarvan het nummber NIET in de subquery staat.
Geef anders ns n paar voorbeeldrecords.

Een versimpelde weergave

code:

partijnr        aantal     jaar      maand
123              60           2004    1
456              100         2004    1
123              60           2004    2

Ik wil graag weten welke partijen die in maand n op voorraad waren niet meer op voorraad zijn in maand n+1. In dit geval:

code:

SELECT * FROM Tabel 
WHERE Maand = 1 AND Jaar = 2004
AND Partijnr NOT IN (
                            SELECT PartijNr 
                            FROM Tabel 
                            WHERE Maand = 2 and Jaar = 2004)

Dit zou dus met de voorbeelddata partij 456 als resultaat moeten geven. In mijn geval gaf de query geen resultaat.

Als ik de volgende query uitvoer

code:

SELECT * FROM Tabel WHERE Maand = 2 and Jaar = 2004

loopt de query totdat in in Query Analyzer op cancel query klik, ik zie dan wel een aantal rijen die aan het select statement voldoen.

Doe ik deze select met een willekeurige andere maand/jaar combo zijn er geen problemen en wordt de query in minder dan een seconde uitgevoerd.

[Delphi32]

Als je wilt weten wat er mis kan zijn probeer dan deze ook:

code:

DBCC CHECKALLOC 
    (   'database_name' 
            [,  NOINDEX 
                | 
                {   REPAIR_ALLOW_DATA_LOSS 
                    | REPAIR_FAST
                    | REPAIR_REBUILD
                }]
    ) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]

[P_de_B]

Delphi32 schreef op 03 maart 2004 @ 15:42:
Als je wilt weten wat er mis kan zijn probeer dan deze ook:

code:

DBCC CHECKALLOC 
    (   'database_name' 
            [,  NOINDEX 
                | 
                {   REPAIR_ALLOW_DATA_LOSS 
                    | REPAIR_FAST
                    | REPAIR_REBUILD
                }]
    ) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]

CHECKALLOC found 0 allocation errors and 0 consistency errors in database '***.

[Verwijderd]

En een

code:

DBCC CHECKTABLE

dan?

[P_de_B]

Verwijderd schreef op 03 maart 2004 @ 16:23:
En een

code:

DBCC CHECKTABLE

dan?

[rml]P_de_B in "[ SQL2K] Tabel corrupt?"[/rml]

[Verwijderd]

Sorry, ff over het hoofd gezien. Kun je de bovenste 20 regels van de output van het checktable geven?

Overigens kun je testen of je tabel corrupt is door de hele tabel in tempdb te zetten en te kijken of je sql-statement nog steeds mis gaat (select * into tempdb..nieuwetabel from bestaandetabel)

[Delphi32]

Stom vraagje misschien, maar zijn 'maand' en 'jaar' de werkelijke kolomnamen, of hebben ze in werkelijkheid andere namen?

[EfBe]

Je hebt wel alle service packs geinstalleerd? (open deur, maar toch)

[P_de_B]

Verwijderd schreef op 03 maart 2004 @ 16:58:
Overigens kun je testen of je tabel corrupt is door de hele tabel in tempdb te zetten en te kijken of je sql-statement nog steeds mis gaat (select * into tempdb..nieuwetabel from bestaandetabel)

Ik heb inderdaad alles in een nieuwe tabel gegooid (staat ook in mijn topicstart), en in de nieuwe tabel trad het probleem niet meer op.

Kun je de bovenste 20 regels van de output van het checktable geven?

aan de rijen in de tabel is niets vreemd te zien, tenminste aan degene die ik kan krijgen (de select duurt immers heel lang)

Stom vraagje misschien, maar zijn 'maand' en 'jaar' de werkelijke kolomnamen, of hebben ze in werkelijkheid andere namen

Ja, dat zijn de echte namen. Ik kan me trouwens niet voorstellen dat dat iets uit zou kunnen maken, maar wie weet

Je hebt wel alle service packs geinstalleerd?

met aan zekerheid grenzende waarschijnlijkheid. Ik doe het zelf niet, maar ik kan me niet voorstellen dat het niet gebeurd is. Ik zal morgen nog even checken.

[EfBe]

Ja, dat zijn de echte namen. Ik kan me trouwens niet voorstellen dat dat iets uit zou kunnen maken, maar wie weet

Zijn het toevallig computed columns, gebaseerd op een date field in hetzelfde record?

[ Voor 3% gewijzigd door EfBe op 03-03-2004 22:01 ]

[P_de_B]

Zijn het toevallig computed columns, gebaseerd op een date field in hetzelfde record?

Nee, het zijn gewoon integer kolommen.