Kyk vir veranderinge aan 'n SQL Server-tabel?

Question

Hoe kan ek 'n SQL Server-databasis monitor vir veranderinge aan 'n tabel sonder om snellers te gebruik of die struktuur van die databasis op enige manier te verander?My voorkeur programmering omgewing is .NET en C#.

Ek wil graag enigeen kan ondersteun SQL Server 2000 SP4 of nuwer.My toepassing is 'n datavisualisering vir 'n ander maatskappy se produk.Ons kliëntebasis is in die duisende, so ek wil nie vereistes instel dat ons die derdeparty-verskaffer se tabel by elke installasie moet verander nie.

Deur "veranderinge aan 'n tabel" Ek bedoel veranderinge aan tabeldata, nie veranderinge aan tabelstruktuur nie.

Uiteindelik wil ek graag hê dat die verandering 'n gebeurtenis in my toepassing aktiveer, in plaas daarvan om met 'n interval vir veranderinge te kyk.

---

Die beste manier van aksie gegewe my vereistes (geen snellers of skemawysiging, SQL Server 2000 en 2005) blyk te wees om die BINARY_CHECKSUM funksioneer in T-SQL.Die manier waarop ek beplan om te implementeer, is die volgende:

Elke X sekondes voer die volgende navraag uit:

SELECT CHECKSUM_AGG(BINARY_CHECKSUM(*))
FROM sample_table
WITH (NOLOCK);

En vergelyk dit met die gestoorde waarde.As die waarde verander het, gaan deur die tabel ry vir ry deur die navraag te gebruik:

SELECT row_id, BINARY_CHECKSUM(*)
FROM sample_table
WITH (NOLOCK);

En vergelyk die teruggekeerde kontrolesomme met gestoorde waardes.

Answer 1

Kyk na die CHECKSUM-opdrag:

SELECT CHECKSUM_AGG(BINARY_CHECKSUM(*)) FROM sample_table WITH (NOLOCK);

Dit sal dieselfde getal gee elke keer as dit uitgevoer word solank die tabelinhoud nie verander het nie.Sien my plasing hieroor vir meer inligting:

KONTROLESOM

Hier is hoe ek dit gebruik het om kasafhanklikhede te herbou toe tabelle verander het:
ASP.NET 1.1 databasiskasafhanklikheid (sonder snellers)

Answer 2

Ongelukkig werk CHECKSUM nie altyd behoorlik om veranderinge op te spoor nie.

Dit is slegs 'n primitiewe kontrolesom en geen sikliese oortolligheidkontrole (CRC) berekening.

Daarom kan jy dit nie gebruik om alle veranderinge op te spoor nie, bv.g.simmetriese veranderinge lei tot dieselfde KONTROLESOM!

E.g.die oplossing met CHECKSUM_AGG(BINARY_CHECKSUM(*)) sal altyd 0 lewer vir al 3 tabelle met verskillende inhoud:

SELECT CHECKSUM_AGG(BINARY_CHECKSUM(*)) FROM 
(
  SELECT 1 as numA, 1 as numB
  UNION ALL
  SELECT 1 as numA, 1 as numB
)  q
-- delivers 0!


Kies Checksum_Agg (binary_checksum (*)) uit (kies 1 as numa, 2 as numb union almal kies 1 as numa, 2 as numb) q - lewer 0!

Kies Checksum_agg (binary_checksum (*)) uit (kies 0 as numa, 0 as numb union almal kies 0 as numa, 0 as numb) q - lewer 0!

Answer 3

Hoekom wil jy nie snellers gebruik nie?Dit is 'n goeie ding as jy dit korrek gebruik.As jy dit gebruik as 'n manier om verwysende integriteit af te dwing, is dit wanneer hulle van goed na sleg gaan.Maar as jy dit vir monitering gebruik, word hulle nie regtig as taboe beskou nie.

Answer 4

Hoe gereeld moet jy kyk vir veranderinge en hoe groot (in terme van rygrootte) is die tabelle in die databasis?As jy die CHECKSUM_AGG(BINARY_CHECKSUM(*)) metode wat deur John voorgestel is, sal dit elke ry van die gespesifiseerde tabel skandeer.Die NOLOCK wenk help, maar op 'n groot databasis slaan jy steeds elke ry.Jy sal ook die kontrolesom vir elke ry moet stoor sodat jy kan sien dat een verander het.

Het jy dit oorweeg om vanuit 'n ander hoek hierna te gaan?As jy nie die skema wil verander om snellers by te voeg nie (wat sin maak, dit is nie jou databasis nie), het jy dit oorweeg om met die toepassingsverskaffer te werk wat wel die databasis maak?

Hulle kan 'n API implementeer wat 'n meganisme bied om bykomstige toepassings in kennis te stel dat data verander het.Dit kan so eenvoudig wees soos om na 'n kennisgewingstabel te skryf wat 'n lys van watter tabel en watter ry gewysig is.Dit kan geïmplementeer word deur snellers of toepassingskode.Van jou kant af sou dit nie saak maak nie, jou enigste bekommernis sou wees om die kennisgewingtabel op 'n periodieke basis te skandeer.Die prestasietreffer op die databasis sal baie minder wees as om elke ry vir veranderinge te skandeer.

Die moeilike deel sou wees om die toepassingverkoper te oortuig om hierdie kenmerk te implementeer.Aangesien dit heeltemal deur SQL via snellers hanteer kan word, kan u die grootste deel van die werk vir hulle doen deur die snellers te skryf en te toets en dan die kode na die toepassingverkoper te bring.Deur die verkoper die snellers te laat ondersteun, voorkom dit die situasie waar u die byvoeging van 'n sneller per ongeluk 'n sneller vervang wat deur die verkoper verskaf is.

Answer 5

Ongelukkig dink ek nie dat daar 'n skoon manier is om dit in SQL2000 te doen nie.As jy jou vereistes beperk tot SQL Server 2005 (en later), dan is jy in besigheid.Jy kan die SQLDependency klas in System.Data.SqlClient.Sien Navraagkennisgewings in SQL Server (ADO.NET).

Answer 6

Het 'n DTS-werk (of 'n werk wat deur 'n Windows-diens begin word) wat met 'n gegewe interval loop.Elke keer as dit uitgevoer word, kry dit inligting oor die gegewe tabel deur die stelsel te gebruik INFORMATION_SCHEMA tabelle, en teken hierdie data in die databewaarplek aan.Vergelyk die data wat teruggestuur is oor die struktuur van die tabel met die data wat die vorige keer teruggestuur is.As dit anders is, dan weet jy dat die struktuur verander het.

Voorbeeldnavraag om inligting oor al die kolomme in tabel ABC terug te gee (ideaal is 'n lys van net die kolomme van die INFORMATION_SCHEMA-tabel wat jy wil hê, in plaas daarvan om *kies ** te gebruik soos ek hier doen):

select * from INFORMATION_SCHEMA.COLUMNS where TABLE_NAME = 'ABC'

Jy sal verskillende kolomme en INFORMATION_SCHEMA-aansigte monitor, afhangende van hoe jy presies "veranderinge aan 'n tabel" definieer.

Answer 7

Wilde raaiskoot hier:As jy nie die derde party se tabelle wil wysig nie, kan jy 'n aansig skep en dan 'n sneller op daardie aansig plaas?

Answer 8

Gaan die laaste toewydingsdatum na.Elke databasis het 'n geskiedenis van wanneer elke commit gemaak word.Ek glo dit is 'n standaard van ACID-voldoening.