windows - Omdirigere SQL Server hændelser fra std Application log ind på en brugerdefineret

Indlæg af Hanne Mølgaard Plasc

Problem



Måtte sive igennem masser af informationer, der forsøger at genoprette rækkefølgen af ​​begivenheder, der førte til et sammenbrud i går, og fik virkelig interesse i at finde en løsning for at offload hændelser fra SQL Server til en brugerdefineret hændelseslog. Google giver kun et enkelt lovende resultat, med linket til en guide til oprettelse af brugerdefinerede logfiler. [2] [3]


Selvom jeg ikke ville gå så langt som at kalde SQL-begivenheder meningsløse (selvom aftalt, 17101 og 17103 stavede ud ' (c) 20 Microsoft Corporation ' og ' Alle rettigheder forbeholdes. 'ved hver genstart er et bestemt affald!),

IMHO, det ville helt sikkert være nyttigt og gavnligt at omdirigere SQL-begivenheder til sin egen log!

Helvede, selv IE har fået en, indbygget! Hvorfor kan 't SQL Server tage det som en bedre praksis at implementere? Specielt på Vista/Win7, som giver tonsvis af individuelle logfiler til masser af andre apps - helt ubrugelig IMHO (aldrig haft noget behov for at grave deri), men tvinger brugergrænsefladen til at bremse til en krybning hver gang du åbner den: [4]


Snapshot of Event Log visning i MMC på Win7


Jeg følger med succes retningslinjerne for oprettelse af en 'SQLServer' brugerdefineret log, tilføj kildedefinitionerne til den. Desværre synes ethvert forsøg på at omdirigere SQL-hændelser til det, at det støder på et problem med MSSQLSERVER (logkilden, der matcher standardnavnet for SQL-tjenesten), som er en slags indbygget kilde:



  EventCreate/l 'SQLServer'/t Information/så MSSQLSERVER/id 1/d 'Log oprettet'

  FEJL: Kildeparameter bruges til at identificere brugerdefinerede applikationer/scripts (ikke indbyggede kilder).



Når jeg markerer MSSQLSERVER under min log som CustomSource (DWORD=1), forsvinder fejlen ovenfor:



  EventCreate/l 'SQLServer'/t Information/så MSSQLSERVER/id 2/d 'Ny post'

  SUCCES: En 'event' type begivenhed oprettes i 'MSSQLSERVER' log/source.



og en begivenhed med ID=2, desc='Ny post' tilføjes til den tilpassede hændelseslog!!   I denne konfiguration skriver den virkelige MSSQLSERVER-tjeneste ikke hændelser til enten denne nye log eller standardfilen 'Application': (. Funktionalitet genoprettes ved at vende tilbage logdefinitioner i registreringsdatabasen (ingen genstart er nødvendig! ), så det er et reversibelt scenario.


Også fra ovenstående ser det ud som Enhver kilde kan kun knyttes til en enkelt log . Logisk nok. Men hvad definerer disse indbyggede kilder, så hvis jeg fjerner de eksplicitte registreringsposter? Måske skulle jeg have genstartet maskinen efter at have foretaget disse ændringer (selvom det ikke var nødvendigt at vende tilbage)?


Har nogen udforsket dette yderligere og måske haft succes?


REDIGER : Hidtil synes det som om, at der er den eneste måde at håndtere dette ved at filtrere MSSQLSERVER (eller andet SQL-servicenavn) hændelser fra visning, som sådan:


Filtrer ud MSSQLSERVER events


Men fanen XML viser, hvad der går under emhætten, og det er ret grimt (som i ekstremt ineffektivt ):


Forespørgsel, der behandles for et sådant filter


Jeg vil have en bedre måde at styre denne begivenhedsdata på, og jeg er sikker på, at jeg ikke er den eneste
Så hvis nogen mennesker hos Microsoft læser dette - noter!

Bedste reference


Errorlog? [5]

Andre referencer 1


Hvis du ønsker at oprette et eventviewerfilter for at ekskludere en bestemt kilde, er XML herefter (undertrykker SQL Express-hændelser fra logfilen 'Application').


<QueryList>
  <Query Id="0" Path="Application">
    <Select Path="Application">*
    </Select>
    <Suppress Path="Application">*[System[Provider[@Name='MSSQL$SQLEXPRESS']]]</Suppress>
  </Query>
</QueryList>


Se hændelsesvalg på MSDN [6]