[SQL] wel lezen niet schrijven probleem

[zneek]

Ik heb een probleempje. Ik heb een SQL Server. Die fungeert als basis voor een ASP website.

Nu gebeurde afgelopen week het volgende: van het ene op het andere moment werkten INSERT, UPDATE en DELETE statements niet meer. SELECT draaide nog prima, en snel ook.

Ik kan me voorstellen dat bij veel gelijktijdige gebruikers zowel de ASP als de SQL minder presteert, en dat er zelfs soms statements niet goed doorkomen (hoewel dit niet zou mogen gebeuren). Er ontstond geen fout oid, maar er trad een ASP timeout op. Alsof er op 1 of andere manier geen toegang te krijgen was tot de DB om te schrijven.

Het enige wat mij verder opvalt aan de hele situatie is de logfile van de betreffende database, die is 20Gb terwijl de database op zich maar 130Mb is.(gevolg van recovery model: full)

Er draaiden geen andere processen op het genoemde moment, ook geen backup e.d. Een uur nadat de schrijfacties wegvielen werkte opeens alles weer.

Iemand ideeen?

[momania]

waaschijnlijk heeft de DBMS in die tijd de transaction log geschoond, zodat er weer update's
etc uitgevoerd kunnen worden.
Als die transactionlog nml. vor is kan de DBMS geen recovery data bijhouden voor jouw
update's, insert's en delete's, terwijl wel aangegeven is dat hij dat moet doen, dus doet hij
dan maar niks meer hiermee en kan je alleen nog maar select'en...

[zneek]

Zoiets vermoed ik ook. Nu nog wat bewijs

Heb je daar wat links ofzo over? Ik ben nu zelf aan het zoeken op www.sql-server-performance.com. Andere info is welkom.

[momania]

Je moet even nagaan of je een roll forward doet bij het restoren van je database, of normale restores
doet of helemaal geen restores.

Doe je geen roll forward dan kan je de recovery log wel uitzetten. De DBMS houdt dan nog wel per
transactie een log bij, maar hergebruikt die weer bij de volgende transacties. Zo loopt iig
de logfile niet uit de klauwen.

Als je wel volledige recovery wil, moet je iedere avond even een backup schedulen. Als het goed
is begint de DBMS na een backup weer met een nieuwe logfile en wordt de logfile dus ook
iig geen 20 Gb meer

[zneek]

Ik heb de oorzaak voor de grote logfile gevonden. De logfile en database files worden wel gebackupped, alleen niet via SQL Server. SQL denkt dus dat alle acties in de logfile nog on-gebackupped zijn, en daarom noodzakelijk om in de logfile te houden.

Dit pas ik zometeen aan. Nu maar hopen dat dat andere probleem niet weer ontstaat. Geen INSERTs is lastig voor een e-commerce site geen orders, doh!

[edit] ^^^^^^^ hehe, dat had ik dus ook net zelf bedacht

[cameodski]

zneek schreef op 05 november 2002 @ 15:27:
Ik heb de oorzaak voor de grote logfile gevonden. De logfile en database files worden wel gebackupped, alleen niet via SQL Server.

Tja, ze hebben niet voor niets maintenance plans in MSSQL zitten. Dan hoeft de backup software dus alleen maar de directory waarin de backups staan te backuppen. De rest kan die gewoon overslaan.
Overigens wordt je log file normaliter opgeschoond op het moment dat je een transaction log backup maakt. Dat soort backups is ook een verbetering voor je performance, behalve dan tijdens het backuppen zelf.
Zelf zorg ik er altijd voor dat elk uur een transaction log backup gemaakt wordt en elke nacht een volledige backup. Na een aantal dagen kun je de oude backups automatisch weer laten verwijderen, dus de harde schijf loopt ook niet zomaar vol. Erg handig die maintenance plans.

Overigens ontstaat ook bij het regelmatig maken van transaction log backups nogal eens wat lege ruimte in de log file, maar ook dat probleem is op te lossen door de database te shrinken. En ook dat is weer te schedulen.

[zneek]

ok thanx.

Maar denk je dat die transaction log de oorzaak van failende insert en update statements kan zijn?

[momania]

zneek schreef op 05 november 2002 @ 15:42:
ok thanx.

Maar denk je dat die transaction log de oorzaak van failende insert en update statements kan zijn?

Ja tuurlijk, je geeft aan bij de DBMS dat hij recovery data moet bijhouden en
op het moment dat dat niet meer kan, kan je dus ook niks meer wijzigen in je data...

[zneek]

momania schreef op 05 november 2002 @ 15:47:
[...]

Ja tuurlijk, je geeft aan bij de DBMS dat hij recovery data moet bijhouden en
op het moment dat dat niet meer kan, kan je dus ook niks meer wijzigen in je data...

Ja maar, de file op zich is het probleem niet. Er is genoeg schijfruimte. Het enige wat het kan zijn is dat ie zo lang nodig heeft om de transaction log te laten groeien dat ie daardoor tijdelijk geen insert, update en delete statements meer toestaat. Maar dat zou betekenen dat ie daar een uur mee bezig is geweest. Lijkt me toch raar.

[cameodski]

zneek schreef op 05 november 2002 @ 15:55:
Ja maar, de file op zich is het probleem niet. Er is genoeg schijfruimte. Het enige wat het kan zijn is dat ie zo lang nodig heeft om de transaction log te laten groeien dat ie daardoor tijdelijk geen insert, update en delete statements meer toestaat. Maar dat zou betekenen dat ie daar een uur mee bezig is geweest. Lijkt me toch raar.

Ik heb thuis wel eens wat zitten pielen met een of andere versie van MSSQL 2000 waarbij de .mdf en .ldf niet groter mochten worden dan 4GB. Mogelijk ligt het maximum bij jou op 20GB.
Je kunt als het goed is wel gewoon een extra .mdf of .ldf toevoegen, dus eventueel kun je dat voor de zekerheid ook nog doen.

[Annie]

Heb je al in je application logs gekeken wat SQL Server zegt over de oorzaak van de problemen (foutmeldingen)?

offtopic:
btw. je hebt een e-commerce site waarbij je database van levensbelang is en er is niet voldoende kennis om het geheel in de lucht te houden? Misschien tijd om je baas wat folders van cursussen toe te schuiven

[zneek]

Annie schreef op 05 november 2002 @ 17:34:
Heb je al in je application logs gekeken wat SQL Server zegt over de oorzaak van de problemen (foutmeldingen)?

offtopic:
btw. je hebt een e-commerce site waarbij je database van levensbelang is en er is niet voldoende kennis om het geheel in de lucht te houden? Misschien tijd om je baas wat folders van cursussen toe te schuiven

Nee, in de lucht houden is geen probleem.

Af en toe van dit soort rare dingetjes.