Toon posts:

[SQL 2008] Random crash zonder dumps

Pagina: 1
Acties:

Verwijderd

Topicstarter
Sinds een paar weken crashed onze sqlserver, meestal 's nachts zonder dat ik een goede aanleiding kan vinden.

De configuratie is als volgt:
Windows 2008 standard SP2 64bit
SQL server 2008 SP3

Het gaat om een virtuele machine met 4 cores en 12GB geheugen toegewezen.
In het logboek krijg ik foutmeldingen m.b.t. sqlservr.exe zoals:
Toepassing met fout sqlservr.exe, versie 2007.100.2531.0, tijdstempel 0x49d03092, module met fout ntdll.dll, versie 6.0.6002.18541, tijdstempel 0x4ec3e855, uitzonderingscode 0xc0000006, foutmarge 0x0000000000036304, proces-id 0x1f38, starttijd van toepassing 0x01ce844bb90bf1be.

Toepassing met fout sqlservr.exe, versie 2007.100.5512.0, tijdstempel 0x5035e693, module met fout ntdll.dll, versie 6.0.6002.18541, tijdstempel 0x4ec3e855, uitzonderingscode 0xc0000005, foutmarge 0x0000000000039520, proces-id 0xe8c, starttijd van toepassing 0x01ce8e8573b309f1.

Nadat de service gecrashed is kan ik hem niet herstarten maar een volledige server herstart lost het probleem op.

Zodra ik de server herstart heb maakt hij een nieuw sql logbestand aan.
De laatste regel in het oude logbestand is een melding zoals deze:
2013-08-01 00:00:21.83 spid17s This instance of SQL Server has been using a process ID of 1784 since 25-7-2013 14:32:25 (local) 25-7-2013 12:32:25 (UTC). This is an informational message only; no user action is required.
In het nieuwe logbestand zie ik meldingen zoals onderstaand maar alle databases starten prima op en het systeem functioneert weer naar behoren:
2013-08-01 09:10:09.26 spid7s 3 transactions rolled forward in database 'master' (1). This is an informational message only. No user action is required.

Ondernomen stappen zover:
SP3 geinstalleerd op de sql server. Ten tijde van de eerste crashes draaide hij nog op SP2.
Shadowcopy uitgezet op fysieke schijf waarop de virtuele schijfbestanden staan i.v.m. ruimtegebrek(uitbreiding staat op de planning maar crisistijd dus dat komt pas later dit jaar.)
Backups van de virtuele machine als test uitgeschakeld gezien hij in het begin altijd crashte terwijl de backup liep. Latere crashes vonden echter ook buiten de backups plaats.
Gezocht naar sql dumps ter analyse, maar deze worden niet gegenereerd. Alles wat ik tegenkom op internet over dit soort problemen verwijst naar de dump files in de logfolder maar deze zijn er niet.
Geheugen van de virtuele machine van 8 naar 12GB gebracht en max memory voor de SQL server op 10GB gezet.
Dit laatste heeft er voor gezorgd dat de crashes bijna een week uitgebleven zijn i.p.v. bijna elke dag maar het probleem blijft terugkomen.

De hoofdvraag in eerste instantie is eigenlijk waarom hij crashed zonder dat hij een dump genereert?
Met de dump zou ik waarschijnlijk een stuk verder kunnen komen.

  • Rolfie
  • Registratie: Oktober 2003
  • Laatst online: 07:42
corrupt memory misschien?

  • chaoscontrol
  • Registratie: Juli 2005
  • Laatst online: 22:01
Ook mijn eerste guess. Controleer het geheugen eens van deze bak? :)

Inventaris - Koop mijn meuk!


  • batsma
  • Registratie: April 2005
  • Niet online
staat daar niet dat de module die de fout veroorzaakt ntdll.dll is?
als dat inderdaad het geval is zou er ook wel eens corruptie op OS niveau kunnen zijn.

  • Oogje
  • Registratie: Oktober 2003
  • Niet online
Kun je de tijdstippen herleiden naar stored procedures die dan draaien? Of bv een backup?

Als ik trouwens ff snel google kom ik vooral met SQL2008 Memory Heap issues tegen die dit kunnen veroorzaken.
Beetje een uitleg over het hoe & wat:
http://blogs.msdn.com/b/s...ng-with-windows-2008.aspx

[ Voor 64% gewijzigd door Oogje op 01-08-2013 15:53 ]

Any errors in spelling, tact, or fact are transmission errors.


  • CMD-Snake
  • Registratie: Oktober 2011
  • Laatst online: 13-11-2022
Hoe zit je over het algemeen qua resources op je virtualisatie host?

Ik heb een keer meegemaakt op een host die behoorlijk aan zijn maximum zat dat als VM's dan verwerkingen begonnen tegelijk de virtualisatie host op 100% resources eindigde. In de VM's resulteerde dat vervolgens in onverklaarbare crashes en VM's die hangen waardoor dingen uiteindelijk crashen.

Verwijderd

Topicstarter
Procedures en backups heb ik al uitgesloten.
Qua resources is alleen de vrije schijfruimte wat problematisch. Dit gaf nogal problemen met de shadowcopy service maar nadat ik die uitgeschakeld heb voor de vm raid is er geen probleem meer geweest.
Geheugen zal ik binnenkort een keer testen tijdens onderhoud maar mijn management console geeft geen ecc errors aan. Plus dat de host en andere vm's geen problemen ondervinden. Het is ook echt alleen specifiek de sql service welke eruit klapt en niks anders.

Wat betreft die heaps. In die mappen staan inderdaad wel txt bestanden maar dus geen dumps.
Qua tijdstippen komen ze echter wel overeen met de crash tijdstippen.

De meeste bevatten de volgende tekst:
<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="sqlservr.exe" FILTER="GRABMI_FILTER_PRIVACY">
</EXE>
<EXE NAME="ntdll.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="ntdll.dll" SIZE="1585152" CHECKSUM="0x83A07D" BIN_FILE_VERSION="6.0.6002.18541" BIN_PRODUCT_VERSION="6.0.6002.18541" PRODUCT_VERSION="6.0.6001.18000" FILE_DESCRIPTION="DLL-bestand voor NT-laag" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Besturingssysteem Microsoft® Windows®" FILE_VERSION="6.0.6001.18000 (longhorn_rtm.080118-1840)" ORIGINAL_FILENAME="ntdll.dll.mui" INTERNAL_NAME="ntdll.dll" LEGAL_COPYRIGHT="© Microsoft Corporation. Alle rechten voorbehouden." VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x184952" LINKER_VERSION="0x60000" UPTO_BIN_FILE_VERSION="6.0.6002.18541" UPTO_BIN_PRODUCT_VERSION="6.0.6002.18541" LINK_DATE="11/16/2011 16:44:05" UPTO_LINK_DATE="11/16/2011 16:44:05" EXPORT_NAME="ntdll.dll" VER_LANGUAGE="Nederlands (Nederland) [0x413]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="kernel32.dll" SIZE="1209856" CHECKSUM="0xAC9C6FC0" BIN_FILE_VERSION="6.0.6002.18740" BIN_PRODUCT_VERSION="6.0.6002.18740" PRODUCT_VERSION="6.0.6002.18740" FILE_DESCRIPTION="DLL-bestand voor Windows NT BASE API-client" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Besturingssysteem Microsoft® Windows®" FILE_VERSION="6.0.6002.18740 (vistasp2_gdr.121127-1435)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. Alle rechten voorbehouden." VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x12C23C" LINKER_VERSION="0x60000" UPTO_BIN_FILE_VERSION="6.0.6002.18740" UPTO_BIN_PRODUCT_VERSION="6.0.6002.18740" LINK_DATE="11/28/2012 04:11:46" UPTO_LINK_DATE="11/28/2012 04:11:46" EXPORT_NAME="KERNEL32.dll" VER_LANGUAGE="Nederlands (Nederland) [0x413]" />
</EXE>
</DATABASE>

[ Voor 68% gewijzigd door Verwijderd op 01-08-2013 17:41 ]


  • demokert
  • Registratie: Mei 2011
  • Laatst online: 16-01 14:05
Als ik je post lees gaat het om een virtuele machine die (neem ik aan) op een ESX omgeving staat.
Dan lijkt het me redelijk standaard dat deze gemonitord worden, en dat defecte hardware redelijk snel opgemerkt wordt (althans bij onze organisatie wel).

Als SQL Crasht is de service dan ook echt gestopt of mag je geen connecties meer creëren ?
Gebeuren de crashes op ongeveer dezelfde tijdstippen of random tijden ?
Lopen er jobs op dat tijdstip ?
Hoeveel databases staan er op de server?
Kun je de ERROR LOG eens posten of PM mag natuurlijk ook! ?

mocht hier niks uitkomen heb ik wel wat ideetjes om er wellicht achter te komen wat de oorzaak van het probleem is.

  • Turdie
  • Registratie: Maart 2006
  • Laatst online: 20-08-2024
SQL maakt ook zelf dumps, zoek daar maar eens op :)

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Je zegt dat je schijfruimte kritisch is, heb je niet een stored procedure oid draaien die giga-temptabellen produceert en daardoor alle schijfruimte inpikt (waardoor er ook geen ruimte meer is voor dumps)

Verwijderd

Topicstarter
@ Shadowman12: Als je mijn verhaal leest geef ik aan dat hij die dumps dus nergens lijkt weg te schrijven. Niet in de appdata/programdata/log mappen in ieder geval.
Wat betreft het logbestand, hier staat dus echt niks nuttigs in maar ik zal hem in je pm zetten.
Crashed op random tijden, bij een crash is de service dus ook echt gestopt. Op de crash tijdstippen lopen er geen jobs. De ene keer is er wel een gebruiker in bezig. De andere keer is er niemand aanwezig.
Er draait maar 1 echte database op. De rest zijn de standaard databases van SQL.

  • Meekoh
  • Registratie: April 2005
  • Laatst online: 16-01 15:13
Verwijderd schreef op woensdag 07 augustus 2013 @ 16:09:
@ Shadowman12: Als je mijn verhaal leest geef ik aan dat hij die dumps dus nergens lijkt weg te schrijven. Niet in de appdata/programdata/log mappen in ieder geval.
Wat betreft het logbestand, hier staat dus echt niks nuttigs in maar ik zal hem in je pm zetten.
Crashed op random tijden, bij een crash is de service dus ook echt gestopt. Op de crash tijdstippen lopen er geen jobs. De ene keer is er wel een gebruiker in bezig. De andere keer is er niemand aanwezig.
Er draait maar 1 echte database op. De rest zijn de standaard databases van SQL.
Ook niet in "C:\ProgramData\Microsoft\Windows\WER"?
Met een beetje mazzel heeft Windows zelf nog een mini dump kunnen maken van het crashende proces. Die komen in de WER (Windows Error Reporting) map terecht.

Indien ESX Wordt het virtuele memory van die bak niet geswapt op dat moment (ballooning). Dat levert soms ook raar gedrag op bij SQL Server.

Computer says no


Verwijderd

Topicstarter
Ik ben ondertussen een stapje verder gekomen. Het lijkt een probleem in de connectie met onze 2K3 DC te zijn. Rond de tijd van de sql server crashes kom ik op de DC een melding tegen in het DNS logboek.
Time-out van de DNS-server tijdens een servicebewerking van Active Directory op ---. Controleer of Active Directory juist functioneert. De fout wordt beschreven in de gegevens van de gebeurtenis.
0000: 00000055

De foutmeldingen variëren maar zijn allemaal in gelijke trend.

Ik heb de DC ook een herstart gegeven ivm updates en zodra de server offline ging crashte de sql service op de andere machine.
Na wat zoeken ben ik er achter gekomen dat de VHD van de database schijf naar een share op de DC verwijst. Door de dns fout is hij even de connectie kwijt en crasht dus alleen de sql server omdat dat de enige applicatie is die op die VHD draait. Als je iets later inlogt dan is de VHD wel gewoon aanwezig in de VM. Erg vreemd maar ik ga de VHD verplaatsen en vermoed dat daarmee de problemen opgelost zijn,

  • sanfranjake
  • Registratie: April 2003
  • Niet online

sanfranjake

Computers can do that?

(overleden)
Draaien de SQL services als een domain-useraccount, of als SYSTEM oid? Probeer dan eens de service te laten starten onder local system en zie of het beter gaat ... Je hebt 1 dc ?

Mijn spoorwegfotografie
Somda - Voor en door treinenspotters


  • ThePowershift
  • Registratie: Oktober 2013
  • Laatst online: 21-12-2025

ThePowershift

De Vakidioot

Kan het ook zijn dat een back-up procedure de boel in de war schopt?

Want ik heb hier ongeveer het zelfde, dat als een back-up wordt gestart, de SQL ook plat gaat en een re-boot van de server de enige oplossing is, meest frapante is dan: binnen een dag heb ik de zelfde ellende weer.

Momenteel de backup op de SQL server uit geschakeld, en wonderlijkerwijs werkt alles nu wel na behoren terwijl de backup is uitgevoerd....

Greetz, ThePowershift

Pagina: 1