Installera SQL Server R Services (i databasen). Eventtjänst i SQL-server


Ofta arbetar basen under "normala" förhållanden. Vad betyder det här:

  • SQL-servern är väl "matad", d.v.s. mängd RAM-minne SQL-arbete servrar bör väljas baserat på 70 % av storleken på alla mdf-databasfiler.
  • Processorn laddas inte mer än 50 % under 90 % av tiden.
  • Det finns tillräckligt med diskutrymme (särskilt temp.db-databasen används för sortering; 1C använder den för alla sina livsaktiviteter, så det är värt att ta hand om diskutrymmet med denna databas i förväg).
  • Databasåterställningsläget är "Enkelt". (Man har empiriskt funnit att en stor ldf-fil saktar ner 1c, och möjligheten att återställa från en loggfil är mycket tveksam).

Det är också värt att överväga flera nyanser:

  • När du använder standardutgåvan av SQL, med en fullständig ombyggnad av indexet, kommer alla användare att kopplas bort från databasen, så det är värt att ta hänsyn till detta när du bestämmer dig för en veckounderhållsplan (planen kommer att beskrivas nedan).
  • Det är värt att tänka på att 1C-servern också förbrukar minne, speciellt om du använder tunna klienter eller webbtjänster.
  • Det är bättre för SQL själv att begränsa den maximala mängden RAM-minne i serverparametrarna, så att när den kritiska massan uppnås börjar den radera onödiga data från RAM-minnet i förväg. Och så att den inte driver hela servern i dvala när den växer.

Under normala förhållanden är det rationellt att använda 2 serviceplaner Varje vecka(en gång i veckan) och Dagligen(på de återstående 6 dagarna i veckan).

Varje vecka

Allmän form

Efter serviceplansartiklar:

  1. Bygger upp indexet igen. Poängen med uppgiften är att ta bort alla befintliga index och installera nya. (grovt sett inventera och ställa allt i ordning).
    Som parametrar:
    • Att välja en målbas (detta kommer att hända i nästan alla uppgifter, så jag kommer inte att uppmärksamma denna parameter längre i den här artikeln).
    • Objekt där vi väljer "Tables and Views".
    • alternativ fritt utrymme– för små volymer hårddisk Du kan välja alternativet "standard", men jag rekommenderar att du använder "Ändra procentandelen ledigt utrymme på sidan", det rekommenderade värdet är 20%. Detta gör att du kan lämna ett utbud av gratissidor och hålla index uppdaterade längre. VARNING: Ökar storleken på databasen.
    • Sortera resultat i tempdb. Jag tror att det inte finns något behov av att förklara, men jag vill varna dig för att vid den här tiden kommer tempdb att växa väldigt mycket, även om sortering i den är utformad för att påskynda processen, var försiktig, ha lite utrymme kvar.
    • Att spara indexet online är en funktion tillgänglig för företagsversionen av SQL. Låter dig indexera om utan att koppla bort klienter.

    !!! UPPMÄRKSAMHET!!! I standardversionen, vid omindexering, kopplas klienter från databasen under hela detta steg.

    Exempelinställningar


  2. Uppdatering av statistik. Uppgiften att samla in information om tillståndet för index i databasen. (I allmänhet har det liten relevans efter omindexering, men jag gör det fortfarande).
    Alternativ:
    • Ett objekt. Alla samma tabeller och vyer som för att bygga om indexet.
    • Uppdatering. Här uppdaterar vi all statistik.
    • Vytyp – Full vy.

    På så sätt uppdaterar vi statistik över hela databasen.

    Exempelinställningar


  3. Exekvera en T-SQL-sats. Detta är exekveringen av ett godtyckligt kommando på SQL-språk, i synnerhet är vi intresserade av dbcc proccache

    Som namnet antyder, rensa cachen.

    Exempel


  4. Kontrollerar databasens integritet. Det verkar onödigt att förklara här – vi ser till att inget går sönder. I parametrarna "inkludera index" i kontrollen var det inte förgäves att de byggdes om.

    Exempelinställningar


  5. Databas backup. Vi måste prata mer här, på grund av många funktioner. Det är bättre att studera det här objektet separat på egen hand i andra guider. Formatet i den här artikeln ger inte en djupgående studie av säkerhetskopiering.
    Men jag vill varna dig för ett par nyanser:
    • SQL vet inte hur man rengör sin behållare, så om du lägger till säkerhetskopior till en fil (den kallas också en "Backup Device"), kommer du att fylla upp allt ledigt utrymme.
    • SQL kommer ihåg sina säkerhetskopior, därför, efter att ha gjort en engångssäkerhetskopia manuellt (till exempel för att ta databasen till en annan plats eller distribuera den för testning till en annan databas från säkerhetskopian), kommer nästa "skillnad" att räknas från det. För att förhindra detta måste du markera "Endast säkerhetskopiering" Det finns inget sådant i säkerhetskopieringsuppgiften. I allmänhet, i en veckoplan rekommenderar jag fortfarande att använda full typ säkerhetskopiering.
    • Och det skulle vara bra att kolla kopian, så att du kan sova lättare.
    • Kompression, i allmänhet, kan användas, men var försiktig, då måste skillnadsvärden också komprimeras.

    Exempelinställningar

  6. Rensa loggen.
    • Backup- och återställningslogg.
    • Agent Quest Log SQL Server.
    • Underhållsplanlogg.

    Jag städar allt. Som namnet antyder rensar den händelser i SQL-loggen. Jag tror att händelser äldre än 4 veckor är osannolikt att intressera mig, för om det finns ett problem, rapportera det inom en månad.

    Exempelinställningar


  7. Operatörsmeddelande. Peka igen för Självstudie. Men som namnet antyder är det för att rapportera problem under genomförandet av planen.

Dagligen

Allmän form

Det är ingen mening att prata separat. Nästan allt är detsamma som Weekly.
Skillnaden ligger i den första uppgiften - "Indexomorganisation". Uppgifterna skiljer sig åt genom att omorganisationen försöker räta upp de befintliga indexen, snarare än att göra allt med ren tavla. Ju större fragmentering, desto oftare kostar det att lansera. Men under normala förhållanden räcker en gång om dagen för att hålla indexet uppdaterat tills nästa ombyggnad.

alternativ


Du kan också använda differentiell backup.

Det är allt. Jag upprepar, jag såg inte någon dogm vid denna tidpunkt. Detta alternativ utvecklades och testades av mig. Relevant för databaser i storlek från 6 till 100 GB.

Jag önskar dig snabbt och pålitligt arbete.
P.S. På grund av att jag inte är en fullfjädrad DBA kanske mina kommentarer är väldigt ytliga så läser jag gärna kommentarerna i kommentarerna och i PM.

Du vet förmodligen att databasunderhåll är ett helt komplex av procedurer: skapa säkerhetskopior, kontrollera integritet, underhålla index, statistik, etc. På Internet (och även på Habré) har många artiklar och rekommendationer skrivits om detta ämne. Men när vi implementerar 1C: Enterprise måste vi ofta hantera det faktum att databasunderhåll är konfigurerat antingen felaktigt eller enligt ett mycket förenklat schema. Till exempel, för att inte bry sig med att hantera transaktionsloggar, är Simple Recovery-modellen installerad för "kamp"-databaser. Och detta trots att förlusten av information på ett par timmar redan är kritisk för företaget. Ibland ingår uppgiften att komprimera databasfiler i regelbundet underhåll ("problemet växte inte"), eller efter uppdatering av indexen förstörs statistik och andra liknande misstag. Detta beror på att företag oftast inte har en erfaren databasadministratör och underhållet måste skötas av en av IT-tjänstmedarbetarna - en "omedveten" databasadministratör (DBA). Samtidigt förstår en sådan DBA inte alltid alla risker och ansvar som tilldelats honom.



För databasunderhåll erbjuder Microsoft underhållsplaner i SQL Server Management Studio (SSMS). Men som praxis visar kan endast en erfaren DBA skapa och konfigurera en högkvalitativ och pålitlig serviceplan. Jag vill notera att tillförlitligt underhåll är så automatiserat som möjligt och inte kräver regelbunden manuell övervakning av administratören, och garanterar även att data kan återställas i händelse av ett fel.

Tredjepartsprogram som finns tillgängliga på marknaden och kan göra livet enklare automatiserar främst skapandet av säkerhetskopior. Valet av sådana program är mycket brett. De låter dig göra komprimerade och krypterade säkerhetskopior till FTP/GoogleDrive/Amazon och så vidare. Säkerhetskopieringar här kan jämföras med räkorna som Bubba pratade om i filmen "Forrest Gump": " ... du kan steka dem, koka dem, baka dem, stuva dem, du kan göra räkkebab, kreolräkor, gumboräkor stekta med ris...».

Men som sagt, att sätta upp säkerhetskopior är inte allt, så sådana program täcker bara en del av problemen.

Som ett resultat måste den "omedvetna" DBA läsa artiklar, förstå SSMS, utveckla en säkerhetskopieringsstrategi, söka efter skript och konfigurera aviseringar. Det tar mycket tid, men det finns alltid något att svära över... Och jag vill leva lugnt! Så att du gör det en gång och glömmer det.

I den här artikeln skulle jag vilja ge en översikt över vårt program Snabbt underhåll och säkerhetskopiering(QMB), som hjälper dig att snabbt och enkelt ställa in databasunderhåll på Microsoft SQL Server. Det är obestridligt att för stora och högt belastade databaser kan du inte klara dig utan en erfaren DBA och individuell prestandajustering, men om du har att göra med många små databaser (vanligtvis upp till 50-80 GB), då detta verktyg kommer att vara användbart för både nybörjare och avancerade användare.

Nyckelfunktioner i QMB

  • Enkel och snabb installation
  • Underhåll av flera SQL-servrar i ett program. SQL Server-versioner 2000 och äldre stöds, inklusive Express-utgåvor
  • 30 inbyggda uppgifter med öppna skript, inklusive populära Ola Hallengren-manus:

    – säkerhetskopior - fullständig, differentiell, transaktionslogg
    – integritetskontroll
    – underhåll av index och statistik
    – underhåll av systemdatabaser
    – kopiering av säkerhetskopior med möjlighet att ange en lagringsperiod
    – automatisk verifiering av säkerhetskopior genom återställning
    – hålla databaskopior uppdaterade

  • 7 fördefinierade underhållspolicyer för Full och Simple återställningsmodeller
  • Övervakning av ledigt utrymme på SQL Server-diskar
  • Användaruppgifter på skriptspråk Transact SQL, CMD, VBScript, JavaScript, PowerShell och andra
  • Statistik över förändringar i databasstorlekar. Beräkning av genomsnittlig datatillväxt
  • Aviseringar av e-post
  • Detaljerad underhållslogg

Den korta videon nedan visar ett heltäckande exempel på serviceinställning med QMB. Följande beskrivning kompletterar videon och talar om några av funktionerna i programmet.

Koncept: tillgänglig för nybörjare, bekvämt för proffs

Å ena sidan försökte vi göra programmet tillgängligt för nybörjare och implementera de vanligaste servicescenarierna. Å andra sidan ville vi göra programmet bekvämt för avancerade användare och hjälpa dem att skapa en mängd olika scenarier, inklusive att kombinera databasunderhållsoperationer med Transact SQL med andra rutinprocedurer för dina applikationer. Till exempel, i QMB kan du skapa ett skript som först laddar data till 1C: Enterprise, och först därefter gör en säkerhetskopia och utför resten av underhållet. Resultatet är en schemaläggare som ger sitt eget ramverk för exekvering T-SQL-skript Och batchfiler(med möjligheten att lagra resultaten av deras utförande).

Arkitektur

Programmet har tre komponenter: en GUI-klient, en QMB-tjänst och en fildatabas för lagring av dess data. Vid installation av QMB installeras alla tre programkomponenter. Underhållsplaner skapas inte, så tjänsten SQL Server Agent krävs inte. Läs mer om arkitektur.

Underhållspolicyer, scenarier och uppgifter

Som nämnts ovan skapar QMB inga underhållsplaner på SQL Server. Istället skapas det Servicepolicy, som sparas i lokal lagring (fildatabas). I huvudsak är en policy en gruppering av databaser med liknande egenskaper som underhålls enligt samma regler. Policyn innehåller en lista över databaser, inställningar för lagring och kopiering av säkerhetskopior. Policyn omfattar en eller flera scenarier service. Manuset innehåller en uppsättning uppgifter, körs sekventiellt för varje (ingår i policyn) databas. Om vi ​​drar en analogi med underhållsplaner kan scenariot jämföras med kapslade underhållsplaner.

En uppgift i QMB kan vara en av fem typer:

  • T-SQL-skript
  • Skapa en säkerhetskopia (T-SQL-skript)
  • Återställa en arkiverad kopia ( dynamiskt skript T-SQL)
  • Anpassat skript (inte T-SQL)
  • Kopiera arkivkopior (används i systemuppgiften med samma namn)
Programmet har två uppsättningar inbyggda uppgifter. Den första uppsättningen uppgifter är baserad på T-SQL-skript erhållna från öppna källor och skapad av QMB-utvecklare. Den andra uppsättningen är baserad på skript av Ola Hallengren (en databasadministratör från Sverige), som utvecklat tre populära lagrade procedurer för att underhålla databaser. Ola procedurer installeras automatiskt i systembas data bemästra, när du skapar en policy från en mall.

Underhåll av stora och små databaser. Policymallar

Du kan skapa en servicepolicy från en mall eller manuellt från början. Aktuell version Programmet innehåller 7 mallar, som huvudsakligen skiljer sig åt:
  • Databasåterställningsmodell. 5 policyer med en fullständig återställningsmodell och 2 med en enkel återställningsmodell.
  • Index underhållsorder. För små databaser utförs indexdefragmentering varje natt, och uppdaterad statistik uppdateras under dagen; För stora databaser utförs indexdefragmentering en gång i veckan.
  • En uppsättning uppgifter som används i scenarier. För underhåll används uppgifter/manus av Ola Hallengren eller QMB.
För produktionsdatabaser med daglig operationell datainmatning (OLTP-databaser) rekommenderas att välja en policy med Fullåterställningsmodell - till exempel för 1C: Företagsdatabaser i vilka data läggs in dagligen. Denna modell låter dig återställa databasen till den aktuella eller till en godtycklig tidpunkt.

Efter att ha skapat en policy från en mall kan du ändra vilken som helst av dess parametrar - scenarier och scheman, uppgifter och meddelandeordning. I framtiden kan den skapade policyn kopieras till andra servrar som är registrerade i programmet.

Mer information om skillnaderna i mallar finns i hjälpen.

Uppgifter

Som nämnts ovan finns det 5 typer av uppgifter i QMB - några av deras funktioner beskrivs nedan.

Utförande av skript

De flesta systemuppgifter är T-SQL-skript. Själva skriptet kan ses i uppgiftsformuläret:

Skripttexter (T-SQL, CMD, VBS, PowerShell och andra) kan innehålla markörer som kommer att ersättas med motsvarande värden innan exekvering. Till exempel en markör ?Databas namn? kommer att ersättas med databasnamnet och token ?BackupDirectory? – till sökvägen till säkerhetskopieringskatalogen som anges i policyn. Full lista markörer finns i hjälpen.

Optimering av underhållsfönster
Det händer att det inom ett begränsat tidsfönster är nödvändigt att inte bara montera databasunderhåll använder SQL Server, men också utförandet av andra rutinoperationer av din applikation. Till exempel att testa och korrigera 1C-databaser, ladda upp med 1C: Enterprise-plattformen, genomföra utbyten osv. Vanligtvis används Windows-uppgiftsschemaläggaren eller 1C: Enterprise-schemaläggaren för detta. Men i det här fallet är det nödvändigt att placera ut procedurerna i tid med god marginal - så att de garanterat inte överlappar varandra. Som ett resultat kanske uppgifter inte passar in i det tillgängliga tidsfönstret.

Med QMB kan du få ut det mesta av underhållsfönstret genom att skripta exekveringen av T-SQL-skript och batchfiler i VBS, JavaScript, CMD, PowerShell och andra. Nedan är ett enkelt exempel på en alternativ säkerhetskopieringsuppgift med hjälp av verktyget Robocopy:

Det bör noteras att batchfilen kan köras både på maskinen där programmet är installerat och på SQL Server-sidan. Detta gör att du kan använda säkerhetskopior på SQL Server-sidan. Du kan till exempel skriva ett skript som kommer att arkivera den senaste säkerhetskopian och ladda upp den till någon molnlagring eller implementera din egen kopieringsalgoritm. I följande artiklar planerar jag att prata mer i detalj om denna möjlighet och tillhandahålla skript för att arbeta med 1C: Enterprise 8-databaser.

Meddelandeutgång och underhållslogg
Alla meddelanden som matas ut under skriptkörning omdirigeras till programunderhållsloggen. Detta gäller meddelanden som matas ut av utskrifts- och raiserror-kommandona för T-SQL-skript, såväl som meddelanden som matas ut till konsolen med ekokommandon för andra CMD-skript och batchfiler. Och det är jättebra! Eftersom läsbara och begripliga loggar är en enorm tidsbesparing, och som en bonus skickas feltexten i ett e-postmeddelande.

Automatisk verifiering av säkerhetskopior genom återställning

Förekomsten av säkerhetskopior betyder inte att det kommer att vara möjligt att återställa data i händelse av ett misslyckande - återställning kan misslyckas av en mängd olika anledningar. Det kan till exempel hända att kedjan av arkivkopior avbryts, och du kommer inte ens veta om det förrän du försöker återställa data. Det är därför bästa praxis säger att en bra DBA regelbundet bör kontrollera de skapade säkerhetskopiorna och utföra återställningar från dem. Det finns helt enkelt inget annat 100-procentigt sätt. Microsoft rekommenderar också att du testar alla säkerhetskopior minst en gång. Uppgifter för automatisk återställning det finns inget alternativ i SSMS, och det finns inte många som är villiga att kontrollera säkerhetskopior manuellt varje dag.

QMB har en speciell uppgift som sekventiellt kommer att återställa hela kedjan av säkerhetskopior för varje policydatabas: Full backup –> Differential backup –> Transaction log backup. Återställning utförs till en temporär testdatabas, som raderas efter kontroll av dess integritet.

I vårt företag finns det till exempel cirka 60 små databaser på en virtuell SQL Server, med en total volym på cirka 100 GB. QMB kontrollerar återställningsförmågan för alla databaser varje natt. Verifieringen tar ungefär en och en halv timme och det ger oss en garanti för att alla säkerhetskopior har verifierats. Om kedjan av säkerhetskopior avbryts kommer du att få ett meddelande med något i stil med detta fel:

1. Uppgift "Återställning från säkerhetskopior till en temporär databas med efterföljande integritetskontroll" (databas: Buh_Oazis)


Sådana fel förekommer sällan, vanligtvis på grund av de anställdas slarv eller okunnighet. I det här fallet gör vi helt enkelt en extra fullständig backup.

Tips till dig som vill sätta upp en sådan check:

  1. Återställningsoperationen är resurskrävande, så den bör inkluderas i skript som endast körs under icke-arbetstid.
  2. För att skapa en tillfällig testdatabas och återställa säkerhetskopior till den krävs en reserv disk utrymme, lika med minst den största databasen i policyn + 10 % av dess volym.
  3. Att återställa stora databaser kan ta avsevärd tid. Aktivera inte en skanningsuppgift om du inte är säker på att operationen kommer att slutföras inom det tilldelade underhållsfönstret.
  4. Placera uppgiften korrekt i skriptet. Observera att återställningen utförs vid den aktuella tidpunkten, dvs. vid tidpunkten för uppgiftens genomförande. Till exempel, om uppgiften att kontrollera säkerhetskopior placeras omedelbart efter att en fullständig säkerhetskopia har skapats, testas endast den sista säkerhetskopian, eftersom det räcker för att återställa databasen till den aktuella tidpunkten.
  5. Om det inte finns tillräckligt med underhållsfönster för att kontrollera säkerhetskopior av alla policydatabaser, kan du kontrollera säkerhetskopior av endast vissa databaser. Eller fördela uppgifter efter veckodag. Kontrollera till exempel säkerhetskopiorna av databaserna A och B ikväll och imorgon – databaserna C och D.
  6. Det rekommenderas inte att säkerhetskopiera en nätverksmapp, eftersom... vid återställning måste du "dra" säkerhetskopior över nätverket, vilket avsevärt ökar återställningstiden. Det skulle vara mer korrekt att ställa in skapandet av säkerhetskopior på en lokal disk med daglig kopiering till en nätverksmapp.

Automatiserat underhåll av databaskopior uppdaterade

Med hjälp av programmet kan du hålla kopior av databaser uppdaterade. Till exempel, för 1C-utvecklare, kan du uppdatera testdatabasen varje natt. För att göra detta måste du skapa en uppgift som liknar den inbyggda "Återställning från arkiv. kopior till en tillfällig databas." I uppgiften måste du ange källdatabasen för säkerhetskopior och databasen till vilken återställningen ska utföras. Och först då placera uppgiften i nattscenariot. Bilden nedan visar en uppgift som återställer säkerhetskopior av Accounting-databasen till AccountingCopy-databasen. Dessutom, om det inte finns någon AccountingCopy-databas på SQL Server, kommer den att skapas automatiskt.

Under återställningsproceduren kommer AccountingCopy-databasen att växlas till enanvändarläge med alla användaranslutningar frånkopplade.

Kopiera säkerhetskopior

Videon visade hur programmet konfigurerar ytterligare kopiering av säkerhetskopior till ett nätverk eller lokal mapp. Genom att kopiera säkerhetskopior kan du i viss mån försäkra dig mot skador på filer, disken eller hela servern. I fall med en virtuell SQL Server kommer kopiering av säkerhetskopior till en riktig fysisk disk att göra att du snabbt kan återställa en eller flera databaser utan att vänta på att hela databasen ska återställas. virtuell maskin.

Nedan skulle jag vilja fokusera på flera funktioner för att kopiera säkerhetskopior med QMB:

  1. Kopieringsfrekvensen bestäms av skriptschemat som innehåller uppgiften "Kopiera arkivkopior". En uppgift kan placeras i ett eller flera scenarier.
  2. Endast nya och ändrade säkerhetskopior kopieras - detta minskar belastningen på nätverket och tillåter frekvent kopiering. Du kan till exempel kopiera varje gång efter att du har skapat en ny säkerhetskopia av transaktionsloggen.
  3. För en nätverksmapp kan du ställa in lagringsperioden för filer. Således kan du lagra säkerhetskopior på en lokal SQL Server-disk, till exempel i 1 vecka, och nätverksmapp på 1 månad.
  4. Det är möjligt att konfigurera säkerhetskopiering endast för utvalda policydatabaser.

Databasåterställning

Du kan återställa databasen i standard SSMS-konsolen. QMB har dock en analog med enklare inställningar:

Kommandot "Återställ från säkerhetskopia" låter dig:

  • Återställ databasen från säkerhetskopior till en angiven tidpunkt från automatiskt val säkerhetskopieringskedjor (om säkerhetskopior skapades på samma SQL-server).
  • Återställ en databas från en fullständig säkerhetskopia.
  • Återställ säkerhetskopior av en databas till en annan databas, inklusive en ny.
  • Utför en databasintegritetskontroll efter att den har återställts.

E-postvarningar

Om du någonsin har använt e-postvarningar i SSMS vet du förmodligen att DataBase Mail-meddelanden innehåller minimal information. Till exempel, vid ett fel, kommer ett meddelande som detta att skickas:
PÅGÅENDE UPPGIFT:
"Databas Workers.NestedPlan_1" startade den 19/05/2015 17:00:00
VARAKTIGHET:
0 timme, 0 minut, 5 sek.
STAT:
Fel
MEDDELANDEN:
Det gick inte att slutföra uppgiften. Uppgiften lanserades av Schedule 9 (MaintenancePlan). Det sista steget som utfördes var steg 1 (Säkerhetskopiering av transaktionslogg).

Från ett sådant meddelande kan du förstå att ett fel har inträffat, men för att förstå vilken typ av fel det är (och bedöma dess svårighetsgrad) måste du titta på serverloggarna. Dessutom kommer Database Mail att skicka ett meddelande varje gång ett fel dyker upp - det är möjligt att du kommer att ha hundratals liknande meddelanden i din post.

Till skillnad från Database Mail skickar QMB de första 15 raderna med feltext i meddelandet. Vanligtvis är detta tillräckligt för att förstå orsaken och vidta nödvändiga åtgärder. Du kan se hela loggen i programunderhållsloggen. Exempel på ett felmeddelande:

Scenariot "Resurskrävande uppgifter för medelstora OLTP-databaser (varje natt)" exekverades med fel på servern "Srv05".

Scenariostart: 06/06/2015 1:00
Slut på arbetet: 2015-06-06 1:29
Längd: 00:29:28

Totalt antal uppgifter: 7
Gjorda uppgifter: 7
Med fel: 1

1. Uppgift "Återställning från säkerhetskopior till en temporär databas med efterföljande integritetskontroll" (databas: IPGor)
Meddelande: 4305, Nivå: 16, Status: 1, Linje: 21
Loggen i denna säkerhetskopia börjar med LSN 5235000000291100001, som ännu inte kan tillämpas på databasen. En tidigare loggsäkerhetskopiering som inkluderar LSN 5228000000281600001 kan återställas.

Meddelande: 3013, Nivå: 16, Status: 1, Linje: 21
ÅTERSTÄLLNINGSLOGG avbröts med ett fel.

Meddelande: 50 000, Nivå: 16, Status: 1, Linje: 119
Ett fel uppstod under återställningsprocessen

Det finns också en mekanism för att förhindra sändning stor kvantitet identiska bokstäver, till exempel om felet upprepas regelbundet.

Licenspolicy och kostnad

Den fullständiga versionen av programmet kan laddas ner från vår hemsida. Äta försöksperiod(30 dagar från datumet för första registrering av SQL Server), varefter en licens måste köpas för varje SQL Server. QMB tillåter dock gratis(med vissa begränsningar) underhålla databaser på SQL Express. Det finns också billiga kommersiella licenser för SQL Express från 1 560 RUB. Den nuvarande kostnaden för en professionell licens för ryska företagär 7100 rub. Specifikationer och priser kan ses.

Licenser är eviga och inte tidsbegränsade. Vid behov kan licensen enkelt överföras från en server till en annan.

Stöd
Från det ögonblick du köper en kommersiell licens kan du rulla ut alla programuppdateringar i 1 år för att installera efterföljande uppdateringar, du måste utöka supporten.

Slutsats

Ibland stöter jag på åsikten att tredjepartsprogram SQL Server ses enbart som en krycka. Att säkerhetskopior eller underhåll som konfigurerats med hjälp av sådana program förmodligen är värre än att använda en vanlig SQL Server-agent. I det här fallet måste jag förklara att SQL Server bara förstår Transact SQL-satser och inte alls bryr sig om det är SQL Server Agent eller något annat program som skickar detta uttalande. Till exempel, för att kontrollera databasens integritet måste han skicka kommandot DBCC CHECKDB, och för att göra en säkerhetskopia – BACKUP DATABAS. Uppenbarligen kommer resultatet alltid att vara identiskt, oavsett vem som skickar detta kommando.

Jag hoppas att du tyckte att denna recension var till hjälp. Kom ihåg att dålig prestanda och plötsliga stopp av SQL Server skadar hela IT-organisationens rykte, medan dataförlust i de flesta fall leder till ännu allvarligare konsekvenser. Om du har skapat en underhållsplan, men inte är säker på dess tillförlitlighet, då sitter du på en tidsinställd bomb - jag råder dig starkt att förebygga en nödsituation i förväg snarare än att ta itu med dess konsekvenser.

Tack för din uppmärksamhet, jag är redo att svara på dina frågor i kommentarerna.

Taggar: Lägg till taggar

Så, om vi fortsätter med att serva 1C-databaser, låt oss ta en närmare titt på kontrollsystemet relationsdatabaser Microsoft data SQL Server. Denna produkt ger oss fantastiska möjligheter för bearbetning, lagring, säkerhetskopiering och återställning av databaser. Jag kommer att starta en kort serie artiklar som ägnas åt detta ämne. Allt som skrivs nedan är en personlig åsikt i denna fråga och är föremål för kritik.

Den här artikeln diskuterar processen för att skapa basunderhållsplaner. Vi kommer att överväga att meddela operatören, samt ett exempel på att återställa databasen, i följande artiklar.

I testlaboratoriet har vi följande:

  • Server Windows Server 2008 Enterprise: SRV-1C-TEST.
  • Microsoft SQL Server 2008: SRV-1C-TEST.
  • Testbas Buh Firma.

Som vanligt satte vi oss själva uppgiften:

Utför basunderhåll mellan 00:30 och 01:00, och underhåll bör inte märkas (eller knappt märkas) för basanvändare.

Låt oss börja med de viktiga punkterna. MS SQL-databas kan ha en av tre typer av återställningsmodeller:

  • Enkel.
  • Full.
  • Med ofullständig loggning.

Vid säkerhetskopiering får vi också tre kopieringsalternativ att välja mellan:

  • Komplett.
  • Skillnad.
  • Kopiera transaktionsloggen (loggar).

Med alternativet för fullständig kopiering sparas mdf-databasen och transaktionsloggen. En differentiell säkerhetskopia (även känd som differentiell) kopierar data som har ändrats sedan den senaste fullständiga säkerhetskopian skapades. Genom att kopiera en transaktionslogg sparas endast själva transaktionsloggen.

Om du väljer den enkla modellen kan du återställa databasen från den senaste differentiella eller fullständiga säkerhetskopian. När vi väljer en fullständig återställningsmodell kan vi återställa databasen upp till en minut och skapa en komplett säkerhetskopia, till exempel på natten och på dagen, skapa kopior av transaktionsloggen. Nedan ser vi var denna punkt kommer upp. Jag skulle också vilja citera några utdrag från MSDN: "Den bulkloggade återställningsmodellen är enbart avsedd som ett komplement till den fullständiga återställningsmodellen. I allmänhet liknar den bulkloggade återställningsmodellen, förutom att de flesta bulkoperationer loggas i den i minimal utsträckning."

Du kan se återställningsmodellen för din databas genom att till exempel gå till databasegenskaperna Buh Firma och gå till raden - Parametrar.

I MSSQL 2008 är standardåterställningsmodellen i skapade databaser Full.

Hur väljer man en återställningsmodell? Vi behöver bara svara på frågan: är förlusten av information ödesdiger under den tid som förflutit efter en fullständig säkerhetskopiering? Om svaret är ja, välj den fullständiga återställningsmodellen om inte, välj den enkla. Bulkloggningsmodellen bör endast användas under omfattande databasoperationer.

Så om du väljer enkel modell, då kommer du att kunna återställa data endast vid tidpunkten för nattlig full eller differentiell kopiering, och efter det kommer användarna att återställa all information manuellt. När du väljer Full-modellen måste du säkerhetskopiera transaktionsloggen, annars kommer loggarna att växa avsevärt. Med alla återställningsmodeller bör du alltid ha en fullständig säkerhetskopia.

Först kommer vi att skapa en nattlig basunderhållsplan, som inkluderar sekvensen av följande åtgärder:

  • Kontrollerar databasens integritet
  • Bygger upp indexet igen
  • Uppdatera statistik
  • Rensa DBMS-procedurcachen
  • Databas backup
  • Städning efter service
  • Rensa loggen

För att göra detta, anslut till MSSQL-servern med hjälp av miljön Microsoft SQLServer Management Studio. Du kan starta miljön genom att gå till Start - Alla program - Microsoft SQL Server 2008.

Låt oss ta kontakt med SQL-server och låt oss gå till Management - Serviceplaner. Högerklicka på Serviceplaner och välj Skapa en serviceplan. Låt oss ge honom ett namn: SRV1CTEST.

Före oss är SRV1CTEST-fönstret, där vi kommer att skapa sekvensen av åtgärder som indikeras tidigare. Vi ser det direkt dyka upp Nested_Plan1. Till höger om namnet på den kapslade planen ser du en skyltformad ikon. Klicka på den och gå till egenskaperna för uppgiftsschemat. Här kan du ändra namnet på den kapslade planen, ställa in upprepningsfrekvensen till Dagligen och ställ in tiden. Och så nu återstår att fylla vår plan med uppgifter. För att göra detta, från Verktygsfältet, som finns på höger sida, dra uppgifter.

Låt oss börja med Databasintegritetskontroller.

När du har dragit uppgiften dubbelklickar du på den. Ett fönster öppnas där vi på raden Databas väljer vår skapade databas Buh Firma. Lägg sedan till uppgifter på samma sätt Bygger upp indexet igen Och Uppdatera statistik, glöm inte att välja önskad databas i dem.

Procedur Bygger upp indexet igenåterskapar indexet med en ny fyllningsfaktor. På grund av detta ökar vi prestanda för arbetet i databasen.

Uppgift Uppdatera statistik Uppdaterar tabelldatainformation för MS SQL. Vilket också förbättrar produktiviteten. Men efter denna operation är det nödvändigt att rensa cachen.

Låt oss stanna till nu och prata om att skapa kopplingar mellan uppgifter. Anslutningarna återspeglar sekvensen för utförande. För att göra en koppling mellan uppgifter måste du klicka en gång på uppgiften och du kommer att se en pil visas. Hon måste dras till nästa uppgift. Anslutningen kan ha 3 färger: blå, grön och röd, som var och en betyder tre typer av övergångsavfyrning: vid enkel slutförande av föregående uppgift - Komplettering, i händelse av framgångsrikt slutförande - Framgång, och om ett fel uppstår när den föregående uppgiften utförs - Fel. Du kan se alla dessa parametrar genom att högerklicka på pilen mellan uppgifterna. Alltså, om vi behöver Bygger upp indexet igen avskedas först efter framgångsrikt slutförande av uppgiften Kontrollerar databasintegritet, vi måste koppla dem med en pil. Genom att högerklicka på pilen ändrar du dess läge till Framgångsrikt, som vi ser har dess färg ändrats till grönt.

På det här ögonblicket vi har 3 skapade uppgifter i vår kapslade plan. Som du kanske har märkt finns inte uppgiften Rensa DBMS-procedurcachen i verktygsfältet. Vi kommer att använda problemet Exekvera en T-SQL-sats. Låt oss dra den till planen och dubbelklicka på den. Vi ser ett fönster där vi anger följande:

DBCC FREEPROCCACHE

Den här artikeln fick mig att skriva ett problem som jag nyligen löste för en av kunderna.

Närmare bestämt fanns det till och med flera problem som, som vanligt, låg ovanpå varandra (eller så var de "lagrade" av administratörer som försökte lösa problemet).
Artikeln syftar inte till att ge en heltäckande och detaljerad beskrivning av hela Service Broker-systemet, med alla dess möjligheter.
Detta är bara en beskrivning av den miljö som jag stötte på oftast när jag löste problem.
Förmodligen alla som läser denna blogg vet vad Service Broker är i SQL Server, men för att börja med en utgångspunkt kommer jag att säga några ord om den här saken.

Denna användbara funktion dök upp först i SQL Server 2005 och har inte förändrats mycket sedan dess. Närmare bestämt har den vuxit med några nya förmågor, men de principer som fastställdes under dessa år har förblivit oförändrade.
Så.
Som följer från https://technet.microsoft.com/ru-ru/library/ms166049(v=sql.105). aspx, Service Broker hjälper dig att skapa asynkrona, löst kopplade applikationer där oberoende komponenter arbetar tillsammans för att utföra en uppgift. Dessa komponenter utbyter meddelanden som innehåller de data som behövs för att slutföra en uppgift. Det här avsnittet beskriver följande aspekter av Service Broker:
dialoger;

  • effektivisera och samordna meddelanden;
  • transaktionsbaserad asynkron programmering;
  • stöd för löst kopplade applikationer;
  • komponenter i Service Broker-komponenten.

De viktigaste byggstenarna i systemet är:

  • Meddelanden. Block med information som utbyts mellan deltagarna.
  • Avtal. Meddelanden samlas in i ett kontrakt så att meddelandeutbytet blir mer formaliserat.
  • Köer. Meddelanden som ska skickas och tas emot läggs i speciella köer som både avsändaren och mottagaren har.
  • Service. Alla ovanstående komponenter är sammankopplade av en tjänst, som är enheten för interaktion i systemet.
  • Rutter. För att leverera meddelanden till tjänster skapas leveransvägar.
  • Dialog. Ett programmerbart sätt att skicka ett meddelande från en initiativtagare till en mottagare och tillbaka.
  • Transaktioner. All databehandling under överföring och mottagande utförs på transaktionsbasis, exklusive dataförlust.

Min testmiljö inkluderar:

  • Två instanser av SQL Server installerade på olika virtuella maskiner
  • Domänkontrollant.
  • Åtkomstpunkter (slutpunkter) är konfigurerade för använder Windows autentisering.
  • Användare utan inloggningar skapas på båda servrarna med certifikat för ömsesidig autentisering.
  • Certifikat kopierades till båda servrarna med hjälp av backup.

Hur allt fungerar tillsammans. Nedan finns ett förenklat meddelandediagram och dess beskrivning.

1. När det skickas från initiatorn hamnar meddelandet i den interna överföringskön, som är en intern systemtabell sys.sysxmitqueue Genom att exekvera en begäran till den kommer vi att få vad vi förväntade oss.

För att se meddelanden i kön "exponeras" den dynamiska vyn sys.transmission_queue externt, genom att exekvera en fråga som du får nästan samma resultat. Men i denna uppfattning finns det en mycket användbart element, detta är transmissionsstatus-kolumnen som innehåller information om ett fel som uppstod under överföring och bearbetning av meddelandet.
Till exempel: " Anslutningsförsök misslyckades med felet: '10061(Ingen anslutning kunde göras eftersom måldatorn aktivt vägrade det.)'.”
Meddelandet loggas också i transaktionsloggen, vilket säkerställer dess transaktionsbearbetning.

Alla meddelanden från alla skapade tjänster passerar genom denna interna tabell och följaktligen genom visning, och om det inte finns några fel, sänds de vidare. Meddelanden kan krypteras med certifikat före överföring. Huruvida meddelanden är krypterade eller inte beror på inställningarna i dialogrutan som initierar anslutningen.
2. Efter att meddelandet har placerats i överföringskön (sys.transmission_queue), utförs dess klassificering.
Kärnan i klassificeringen är att bestämma var tjänsten som detta meddelande är adresserad till finns. För att bestämma riktningen för överföringen används leveransvägar som skapats under tjänsteinstallationsfasen. I I detta fall två rutter är konfigurerade. Den ena pekar på en fjärrkonsumenttjänst, den andra pekar på en lokal SQL Server-instans för att leverera lokala varningar.

Vi kan se klassificeringssteget körs med SQL Profiler-spårningar om vi väljer händelser relaterade till Service Broker. Observera att några av händelserna relaterade till Service Broker publiceras i avsnittet Säkerhetsrevision.

3. Efter klassificering av meddelandet upprättas en anslutning med en fjärransluten (som i detta fall) anslutningspunkt (Endpoint). I det här fallet är det här en server som använder TCP-protokoll, med namnet SQL2014-I1 och portnumret (Endpoint) 4022. Om ett fel inträffar under anslutningen kommer det att visas i spåret (som visas nedan) och i kolumnen transmission_status i vyn sys.transmission_queue.

4. I nästa steg skickas meddelandet till tjänsten av mottagaren och bekräftas av den mottagande parten. Om du frågar vyn transmission_queue längst ner kommer den att returnera ett tomt resultat, eftersom all data från avsändarkön har överförts.

I spåret på initiativtagaren och avsändaren ser vi bekräftelse på överföringen.

5. Eftersom meddelandet har levererats till mottagaren bör det visas i mottagarens inmatningskö.

Ytterligare, måltjänst ska läsa meddelanden från kön (helst ett i taget) och skicka en bekräftelse på mottagning till den som initierat dialogen. Denna procedur görs med en speciell syntax, som finns i de bifogade skripten https://technet.microsoft.com/en-us/library/bb839483(v=sql.105).aspx.
När data läses från kön blir den tom och bekräftelsemeddelanden skickas till avsändaren (eller inte) i formen, vars sammansättning, och om de skickas eller inte, beror på tjänsteutvecklaren.
Om bekräftelsemeddelanden är programmerade att skickas när kön läses, så följer de samma väg som från mottagaren, endast i omvänd ordning.
I den här bloggen undersökte vi i detalj hela vägen från avsändare till mottagare, och i nästa blogg kommer vi att börja överväga frågor som rör problemlösning med Service Broker i varje steg av bearbetning och överföring.

Alexander Kalenik, Senior Premier Field Engineer (PFE), MSFT (Ryssland)

Ganska ofta behöver utvecklare av klient-serverapplikationer organisera någon form av mekanism som gör att de kan meddela en viss klient baserat på en händelse på SQL-servern. Ännu oftare är det kundens rosafärgade dröm för utvecklaren att implementera en sådan mekanism. Till exempel, om leveransgränser överskrids till någon konsument, måste chefer som arbetar med denna konsument omedelbart meddelas. Vissa systemkunder kräver (och alla kunder, utan undantag, drömmer om detta) att när vissa data ändras uppdateras denna information automatiskt för andra användare av systemet, och omedelbart. Möjligheten av ett sådant krav kommer inte att diskuteras här (det har många skäl för kritik), bara lösningar kommer att diskuteras här. microsoft sql server har standardmedel för anmälningsorganisationer - varningar, men det här verktyget har mycket begränsad användning, vilket i stort sett inte gör det möjligt att skapa en garanterad fungerande mekanism baserad på det. Och här är varför: Kommunikation med klientprogrammet kan åstadkommas genom att skicka ett e-postmeddelande eller emulera ett "net send"-meddelande. Båda är obekväma för att ta emot aviseringar.

E-postverktyget är obekvämt av följande skäl:

a) det finns ingen garanti för leverans, post kan gå förlorad.
b) post kan fastna vid mellanliggande noder.
c) tcp/ip-protokoll krävs
d) en smtp-server krävs och en e-postprofil är konfigurerad.
e) speciell konfiguration av sql-servern krävs så att den kan skicka brev.
f) varje klient som väntar på en händelse måste ha en brevlåda.
g) det är nödvändigt att organisera en e-postklient i klientprogrammet.

Att skicka via "net send" är obekvämt av följande skäl:

a) det finns ingen garanti för leverans, eftersom den organiseras genom postslot-anläggningen, som inte har en sådan garanti.
b) korrekt netbios namnupplösning krävs på nätverket.
c) "Client for Microsoft Networks" krävs på klienten.
d) standardpostplatsen används, detta kan störa andra program.

Och i allmänhet är varningsverktyget obekvämt på grund av behovet av att registrera varje klient som operatör och konfigurera den därefter. De där. För de enklaste fallen kan varningar användas. Men i de flesta fall är det inte tillämpligt.

Kända implementeringar och koncept

Allmänheten känner till flera alternativ för att implementera mekanismen för att meddela klienten från servern. Detta:

1. Skapa ett objekt (extended stored procedure eller activex), genom vilket sql-servern meddelar klienten via tcp/ip-sockets. Samtidigt organiseras telefonavlyssning på klienten, d.v.s. klientprogrammet blev en tcp/ip-server.
Nackdelar med denna metod:
a) Bindning till tcp/ip-protokollet. På ett nätverk där endast ipx, netbeui eller appletalk används kan en sådan mekanism inte användas.
b) Ingen asynkron. Om den här händelsen genereras från en utlösare kommer det att uppstå prestandaproblem.

2. Skapa ett objekt (extended stored procedure eller activex), genom vilket sql-servern meddelar klienten via namngivna pipes eller mailslots. Samtidigt organiseras avlyssning av den ena eller den andra på klienten.
Nackdelar med denna metod:
a) korrekt netbios-namnupplösning krävs på nätverket.
b) Klienten för Microsoft Networks krävs på klienten.
c) vid användning av mailslot finns det ingen garanti för leverans.
d) vid användning av namngivna rör kan detta inte tillämpas på klientdatorer med operativsystemet Windows 95/98/me, eftersom namngivna rör endast kan skapas i operativ system på nt arkitektur.
e) Ingen asynkron. Om denna händelse genereras från en utlösare kommer det att uppstå prestandaproblem.

3. Periodisk avfrågning av SQL-servern av klienten (periodisk läsning av en speciell händelsetabell). Detta är ett mycket enkelt sätt, men ändå fritt från de flesta av ovanstående nackdelar. Tyvärr har denna metod sina egna två specifika nackdelar: a) mottagandet av meddelandet kan försenas av polling-timeout och b) med en liten timeout uppstår betydande trafik. Men med ett litet antal sessioner är denna metod ganska lämplig och ignoreras oförtjänt.

Föreslagen lösning

Vi erbjuder dig en lösning på problemet, fri från ovanstående (alla ovanstående!) problem, men samtidigt ganska enkel. Tanken är denna: ett visst binärt objekt placeras på servern, som sql-servern kan anropa (och detta kan bara vara en utökad lagrad procedur eller ett Activex-objekt), som har två orelaterade metoder.
Den första metoden använder win32api createevent-funktionen för att skapa ett win32-kärnobjekt som kallas "event" med ett unikt namn som skickas som en parameter. Därefter anropas funktionen win32api waitforsingleobject, och när den möter den stannar tråden och väntar tills detta kärnobjekt signalerar. Jag uppmärksammar dig på att hur många sådana kärnobjekt som helst kan skapas. Detta begränsas endast av antalet handtag i systemet.
Den andra metoden anropar kärnhändelseobjektet med det namn som specificeras av parametern med hjälp av win32api setevent-funktionen och ställer in egenskapen "signaled" till den. När detta händer vaknar tråden med den första metoden och återgår kontrollen till anropsprocessen. Den andra metoden väntar inte på ett resultat, utan återställer kontrollen till sin anropsprocess omedelbart efter att ha ställt in egenskapen "signalerad". Detta uppnår asynkroni.
Nu återstår bara att göra de lagrade t-sql-procedurer, hantera detta objekt och den nödvändiga funktionaliteten "i vår ficka". Klientprogrammet, i en separat tråd, startar en lagrad procedur för att vänta på en händelse och skickar ett unikt adressattribut som en parameter. Detta kan vara ett användarnamn, ett datornamn eller vilken sträng som helst. Huvudsaken är att detta är en unik identifierare inom klient-serversystemet. Den lagrade proceduren returnerar endast ett resultat om en händelse genereras för denna destination. När en händelse tas emot, startas proceduren om. När programmet är stängt avslutas tråden som väntar på händelsen helt enkelt via terminatethread.
Vid första anblicken har denna metod en "hemsk" nackdel - det finns en konstant anslutning till sql-servern, som för det mesta inte gör någonting. Men detta är bara det första intrycket. Faktum är att resurser endast används här för att upprätthålla anslutningen - det är ungefär flera kilobyte per session. Det är allt! Inga fler materiella resurser kommer att slösas bort, särskilt med tanke på de fördelar som beskrivs nedan. Du behöver inte heller oroa dig för ytterligare licenser om du väljer licensmodellen "per server". I det här fallet kan en maskin ha så många anslutningar till sql-servern som önskas, det tar fortfarande exakt en klientlicens.

Färdig lösning

Lösningen består av ett activex-objekt i form av en fil algoevt.dll och två lagrade procedurer spwaitforevent och spraiseevent. Före användning måste den här filen placeras på servern och Activex-objektet måste registreras med hjälp av systemverktyget regsvr32.exe. Vidare kommer allt arbete att utföras genom lagrade procedurer. Den färdiga lösningen implementerar något mer funktionalitet än det beskrivna konceptet. Utöver händelsen kan du också överföra godtycklig information i form av en sträng på upp till 250 tecken. Varje procedur har två parametrar. Den första är den unika adressidentifieraren som nämns ovan, och den andra parametern är ytterligare överförd information. spwaitforevent måste anropas från klienten från en separat tråd (den lägsta trådprioriteten kan väljas). När en händelse tas emot måste proceduren startas om. Tidsgränsen för utförande av begäran måste ställas in på oändlig.


2024 gtavrl.ru.