MS SQL Server. Întreținerea bazei de date a sistemului

Adnotare: Gestionați Serviciile SQL Server– aceasta este o chestiune foarte delicată și necesită cunoștințe specifice despre principiile de funcționare ale componentelor serviciului: – Agent SQL Server, Coordonator de tranzacții distribuite Microsoft și Căutare Microsoft. Se are în vedere accesul la parametrii sistemului care se schimbă frecvent. Instrumentele SQL Server Service Manager, SQL Server Enterprise Manager și instrumentele Windows 2000 Service Control Manager oferă capabilități avansate de gestionare a serviciilor. Notele sunt furnizate pentru a proteja administratorii de acțiuni incorecte.

Odată ce instalați Microsoft SQL Server 2000, puteți începe să îl utilizați. Dar înainte de a vă putea conecta și de a începe să vă construiți baza de date, trebuie să aflați cum să porniți un serviciu SQL Serverși componentele sale - Agent SQL Server, coordonator de tranzacții distribuite MicrosoftŞi Căutare Microsoft. Aceste componente, descrise în acest capitol, rulează ca servicii separate care completează serviciul SQL Server. În această prelegere, vă vom arăta, de asemenea, cum să porniți, să opriți și să gestionați aceste servicii folosind trei instrumente - și.

Nota. Această prelegere se concentrează pe descrierea modului în care funcționează SQL Server 2000 sistem de operare Microsoft Windows 2000, deși SQL Server 2000 poate rula și pe Microsoft Windows NT 4. În sistemul de operare sistem Microsoft Windows 98 SQL Server pornește ca fișier executabil deoarece Windows 98 nu acceptă servicii.

Este important să învățați cum să gestionați serviciul SQL Server 2000 folosind Manager de întreprindere. Vă rugăm să rețineți că această prelegere oferă doar o scurtă introducere în Enterprise Manager. Multe probleme rezolvate cu folosind Enterprise Managerul va fi discutat în următoarele prelegeri. Acestea sunt, de exemplu, sarcini precum crearea de baze de date și obiecte, configurație setări server, configurație gestionarea replicării și replicării, managementul backup-ului. Și o altă prelegere se va concentra pe utilizarea Enterprise Manager pentru a gestiona SQL Server și alte servicii.

Servicii SQL Server

Serviciu este un program sau un proces care îndeplinește funcții de suport specifice pentru alte programe. Când porniți SQL Server, sistemul de operare sistem Windows NT sau Windows 2000 pornește serviciul SQL Server. Acest serviciu gestionează fișierele bazei de date, execută instrucțiuni Transact-SQL (T-SQL), distribuie resurse între conexiunile utilizatorilor concurente, verifică consistența datelor și efectuează multe alte sarcini. Dacă instalați una sau mai multe instanțe ale SQL Server, serviciile pentru instanțele individuale SQL Server vor fi denumite MSSQL$InstanceName, unde InstanceName este numele instanței pe care l-ați atribuit în timpul instalării. În consecință, serviciile Agentului SQL Server pentru instanțe SQL Server vor fi denumite SQLAGENT$InstanceName. Cu toate acestea, toate instanțele de SQL Server vor avea o singură instalare Microsoft Distributed Transaction Coordinator și Microsoft Search.

Primiți componentele software ale acestor trei servicii ca parte a licenței pentru copia dvs. de SQL Server. Agentul SQL Server este instalat implicit la instalarea SQL Server. Dacă nu aveți instalate Microsoft Distributed Transaction Coordinator și Microsoft Search, puteți rula din nou programul de instalare SQL Server pentru a instala aceste componente, care sunt denumite acolo Asistență pentru clienți DTCŞi Căutare text integral, respectiv. Acum vă vom spune ce face fiecare dintre aceste trei servicii.

Agent SQL Server realizează planificarea și executarea sarcinilor, alertelor, avizelor și planurilor de întreținere a bazei de date. Fără acest serviciu, munca unui DBA va deveni mult mai dificilă, dacă nu imposibilă. Datorită SQL Server Agent, puteți automatiza procedurile de rutină de întreținere a bazei de date. De exemplu, puteți crea o lucrare care va efectua automat o copie de rezervă copierea bazei de dateîn fiecare zi la ora 1 dimineața și o altă sarcină care se va îndeplini automat backup jurnalul de tranzacții la fiecare jumătate de oră. Pentru a urmări performanța sistemului dvs., puteți crea o alertă de stare a performanței care vă va anunța dacă este ocupat. procesor central serverul va depăși 90%. Pentru a rezolva astfel de probleme, trebuie să rulați serviciul SQL Server Agent, care poate fi configurat pentru pornire automată când porniți SQL Server sau îl puteți porni manual. Ar trebui să-l configurați să ruleze automat, ceea ce va asigura rularea joburilor, alertelor și notificărilor programate. Administrarea Microsoft SQL Server vă va arăta cum să creați un plan de întreținere a bazei de date, iar Automatizarea sarcinilor administrative vă va arăta cum să Ajutor SQL Server Agent atribuie joburi, alerte și notificări.

Coordonator de tranzacții distribuite Microsoft este un manager de tranzacții, cu care puteți include date din aplicațiile dvs. în tranzacții diverse surse, inclusiv date din baze de date de la computere la distanță. Aceasta înseamnă că cu o singură tranzacție puteți actualiza datele de pe mai multe servere accesibile prin rețea. Managerul de tranzacții se asigură că toate actualizările devin permanente în toate sursele de date (dacă tranzacția este efectuată) sau, în cazul unei erori, că toate modificările sunt anulate în toate sursele de date. (Pentru coordonatorul de tranzacții distribuite Microsoft, consultați Serviciile componente și coordonatorul de tranzacții distribuite Microsoft.)

Porniți serviciul Căutare Microsoft, când aveți nevoie de indexare integrală și de asistență pentru căutare. Indexarea textului complet face posibilă performanță mai mare căutare complexă dintre datele care conțin șiruri de text. De exemplu, puteți căuta cuvinte apropiate de cuvânt dat, sau puteți căuta o anumită expresie.

După cum am discutat deja, există mai multe instrumente disponibile pentru a opri și a porni serviciile SQL Server: SQL Server Service Manager, SQL Server Enterprise ManagerŞi Windows 2000 Service Control Manager. Să vedem mai întâi cum puteți gestiona serviciile SQL Server, agent SQL Server, coordonator de tranzacții distribuite MicrosoftŞi Căutare Microsoft.

Folosind SQL Server Service Manager

Pentru a porni sau opri serviciile SQL Server folosind , face pașii următori(Și, după cum veți vedea, serviciul SQL Server poate fi întrerupt).

Probabil știți că întreținerea bazei de date este un întreg set de proceduri: crearea de copii de siguranță, verificarea integrității, menținerea indicilor, statisticilor etc. Pe Internet (și și pe Habré) au fost scrise multe articole și recomandări pe această temă. Cu toate acestea, atunci când implementăm 1C: Enterprise, de multe ori trebuie să ne confruntăm cu faptul că întreținerea bazei de date este configurată fie incorect, fie conform unei scheme foarte simplificate. De exemplu, pentru a nu te deranja cu gestionarea jurnalelor de tranzacții, modelul Simplu Recovery este instalat pentru bazele de date „de luptă”. Și asta în ciuda faptului că pierderea de informații în câteva ore este deja critică pentru companie. Uneori sarcina de comprimare a fișierelor bazei de date este inclusă în întreținerea regulată („problema nu a crescut”), sau după actualizarea indexurilor, statisticile sunt distruse și alte greșeli similare. Acest lucru se întâmplă deoarece, cel mai adesea, companiile nu au un administrator de baze de date cu experiență, iar întreținerea trebuie să fie gestionată de unul dintre angajații serviciilor IT - un administrator de baze de date (DBA) „involuntar”. În același timp, un astfel de DBA nu înțelege întotdeauna toate riscurile și responsabilitățile care îi sunt atribuite.

Pentru service baze de date Microsoft oferă Planuri de întreținere în SQL Server Studio de management(SSMS). Cu toate acestea, după cum arată practica, doar un DBA experimentat poate crea și configura un plan de servicii de înaltă calitate și fiabil. Aș dori să menționez că întreținerea fiabilă este cât se poate de automatizată și nu necesită monitorizare manuală regulată de către administrator și, de asemenea, garantează că datele pot fi restaurate în cazul unei defecțiuni.

Programele terțe care sunt disponibile pe piață și pot face viața mai ușoară automatizează în principal crearea de copii de rezervă. Alegerea unor astfel de programe este foarte largă. Acestea vă permit să faceți copii de rezervă comprimate și criptate pe FTP/GoogleDrive/Amazon și așa mai departe. Backup-urile de aici pot fi comparate cu creveții despre care a vorbit Bubba în filmul „Forrest Gump”: „ ... le poți prăji, fierbe, coace, tocăni, poți face kebab cu creveți, creveți creoli, creveți gumbo prăjiți cu orez...».

Cu toate acestea, așa cum s-a spus, crearea de copii de siguranță nu este totul, așa că astfel de programe acoperă doar o parte din probleme.

Drept urmare, DBA „involuntar” trebuie să citească articole, să înțeleagă SSMS, să dezvolte o strategie de backup, să caute scripturi și să configureze notificări. Este nevoie de mult timp, dar întotdeauna există ceva de jurat... Și vreau să trăiesc senin! Ca să o faci o dată și să uiți.

În acest articol aș dori să ofer o prezentare generală a programului nostru Întreținere rapidă și backup(QMB), care vă va ajuta să configurați rapid și ușor întreținerea bazei de date pe Microsoft SQL Server. Nu există nicio îndoială că, pentru bazele de date mari și foarte încărcate, nu puteți face fără un DBA experimentat și reglarea individuală a performanței, dar dacă aveți de-a face cu multe baze de date mici (de obicei până la 50-80 GB), atunci acest utilitar va fi util pentru atât începători, cât și utilizatori avansați.

Caracteristicile cheie ale QMB

• Configurare ușoară și rapidă
• Întreținerea mai multor servere SQL într-un singur program. SQL suportat Versiuni de server 2000 și mai vechi, inclusiv edițiile Express
• 30 de sarcini încorporate cu scripturi deschise, inclusiv scenarii populare Ola Hallengren:

  – copii de rezervă - complet, diferențial, jurnal de tranzacții
  – verificarea integritatii
  – menținerea indicilor și statisticilor
  – întreținerea bazelor de date de sistem
  – copierea fișierelor de rezervă cu posibilitatea de a specifica o perioadă de stocare
  – verificarea automată a backup-urilor prin recuperare
  – menținerea la zi a copiilor bazei de date

• 7 politici de întreținere predefinite pentru modelele de recuperare completă și simplă
• Monitorizarea spațiului liber pe discurile SQL Server
• Sarcini personalizate în limbaje de scripting Transact SQL, CMD, VBScript, JavaScript, PowerShell și altele
• Statistici privind modificările dimensiunilor bazei de date. Calculul creșterii medii a datelor
• Notificări de la e-mail
• Jurnal detaliat de întreținere

Concept: accesibil începătorilor, convenabil pentru profesioniști

Arhitectură

Politici de întreținere, scenarii și sarcini

O sarcină în QMB poate fi unul dintre cele cinci tipuri:

• Script T-SQL
• Crearea unei copii de rezervă (script T-SQL)
• Restaurarea unei copii de arhivă (script T-SQL dinamic)
• Script personalizat (nu T-SQL)
• Copierea copiilor de arhivă (utilizată în sarcina de sistem cu același nume)

Întreținerea bazelor de date mari și mici. Șabloane de politici

• Model de recuperare a bazei de date. 5 politici cu un model de recuperare completă și 2 cu un model de recuperare simplu.
• Comanda de întreținere a indexului. Pentru bazele de date mici, defragmentarea indexului este efectuată în fiecare noapte, iar statisticile actualizate sunt actualizate în timpul zilei; Pentru bazele de date mari, defragmentarea indexului se efectuează o dată pe săptămână.
• Un set de sarcini utilizate în scenarii. Pentru întreținere se folosesc sarcini/script-uri Ola Hallengren sau QMB.

După crearea unei politici dintr-un șablon, puteți modifica oricare dintre parametrii acestuia - scenarii și programări, sarcini și ordinea notificărilor. În viitor, politica creată poate fi copiată pentru alte servere înregistrate în program.

Mai multe informații despre diferențele dintre șabloane pot fi găsite în ajutor.

Sarcini

Execuția scriptului

Textele de script (T-SQL, CMD, VBS, PowerShell și altele) pot conține markeri care vor fi înlocuiți cu valorile corespunzătoare înainte de execuție. De exemplu, un marker ?DataBaseName? va fi înlocuit cu numele bazei de date și simbolul ?BackupDirectory? – la calea către directorul de rezervă specificat în politică. Lista completă markerii pot fi găsite în ajutor.

Optimizarea ferestrei de întreținere
Se întâmplă că într-o fereastră de timp limitată este necesar să se încadreze nu numai întreținerea bazei de date folosind SQL Server, ci și execuția altor operațiuni de rutină ale aplicației dumneavoastră. De exemplu, testarea și corectarea bazelor de date 1C, încărcarea folosind platforma 1C: Enterprise, efectuarea de schimburi etc. În mod obișnuit, un planificator este utilizat pentru aceasta Joburi Windows sau 1C: Enterprise planner. Cu toate acestea, în acest caz, este necesar să distanțați procedurile în timp cu o marjă bună - astfel încât să fie garantat să nu se suprapună. Ca urmare, este posibil ca sarcinile să nu se încadreze în fereastra de timp disponibilă.

Cu QMB, puteți profita la maximum de fereastra de întreținere prin scriptarea execuției scripturilor T-SQL și a fișierelor batch în VBS, JavaScript, CMD, PowerShell și altele. Mai jos este un exemplu simplu de sarcină alternativă de copiere de rezervă folosind utilitarul Robocopy:

Trebuie remarcat faptul că fișierul batch poate fi executat atât pe mașina pe care este instalat programul, cât și pe partea SQL Server. Acest lucru vă permite să operați fișiere de rezervă pe partea SQL Server. De exemplu, puteți scrie un script care va arhiva cea mai recentă copie de rezervă și o va încărca în oricare stocare în cloud sau implementați propriul algoritm de copiere. În următoarele articole am de gând să vorbesc mai detaliat despre această oportunitate și să ofer scripturi pentru lucrul cu bazele de date 1C: Enterprise 8.

Ieșire mesaj și jurnal de întreținere
Toate mesajele ieșite în timpul execuției scriptului sunt redirecționate către jurnalul de întreținere al programului. Acest lucru se aplică mesajelor trimise de comenzile print și raiserror pentru scripturile T-SQL, precum și mesajelor trimise către consolă prin comenzi echo pentru alte scripturi CMD și fișiere batch. Și asta e grozav! Deoarece jurnalele lizibile și ușor de înțeles economisesc timp enorm și, ca bonus, textul erorilor este trimis într-o notificare prin e-mail.

Verificarea automată a backup-urilor prin recuperare

QMB are sarcină specială, care va restabili secvențial întregul lanț de copii de siguranță pentru fiecare bază de date de politici: Backup complet –> Backup diferențial –> Backup jurnal de tranzacții. Recuperarea este efectuată într-o bază de date de testare temporară, care este ștearsă după verificarea integrității acesteia.

De exemplu, în compania noastră există aproximativ 60 de baze de date mici pe un server SQL virtual, volum total sub 100 GB. QMB verifică capacitatea de recuperare a tuturor bazelor de date în fiecare noapte. Verificarea durează aproximativ o oră și jumătate și asta ne oferă garanția că toate backup-urile au fost verificate. Dacă lanțul de copii de siguranță este întrerupt, veți primi o notificare cu ceva de genul acesta:

1. Sarcina „Recuperare din copiile de rezervă într-o bază de date temporară cu verificarea ulterioară a integrității” (bază de date: Buh_Oazis)

Sfaturi pentru cei care doresc să înființeze un astfel de control:

1. Operația de restaurare necesită un consum mare de resurse, așa că ar trebui să fie inclusă în scripturi care sunt executate numai în timpul orelor de lucru.
2. Pentru a crea o bază de date de testare temporară și pentru a restabili copii de siguranță pe aceasta, este necesară o rezervă spațiu pe disc, egal cu cel puțin cea mai mare bază de date din politică + 10% din volumul acesteia.
3. Restaurarea bazelor de date mari poate dura mult timp. Nu activați o sarcină de scanare decât dacă sunteți sigur că operația va fi finalizată în fereastra de întreținere alocată.
4. Plasați sarcina corect în script. Vă rugăm să rețineți că restaurarea este efectuată în momentul actual, adică la momentul executării sarcinii. De exemplu, dacă sarcina de verificare a copiilor de rezervă este plasată imediat după crearea unei copii complete copie de rezervă, atunci va fi testată doar cea mai recentă copie de rezervă, deoarece va fi suficient să restaurați baza de date la momentul curent.
5. Dacă nu există suficientă fereastră de întreținere pentru a verifica copiile de siguranță ale tuturor bazelor de date de politici, puteți verifica copiile de siguranță ale anumitor baze de date. Sau distribuiți sarcinile în funcție de ziua săptămânii. De exemplu, verificați copiile de siguranță ale bazelor de date A și B în seara asta, iar mâine - bazele de date C și D.
6. Nu este recomandat să faceți copii de siguranță într-un folder de rețea, deoarece... la restaurare, trebuie să „trageți” fișierele de rezervă în rețea, ceea ce crește semnificativ timpul de recuperare. Ar fi mai corect să configurați crearea de copii de rezervă pe un disc local cu copierea zilnică într-un folder de rețea.

Menținerea automată a copiilor bazei de date la zi

În timpul procedurii de recuperare, baza de date AccountingCopy va fi comutată în modul utilizator unic cu toate conexiunile utilizatorului deconectate.

Copierea fișierelor de rezervă

Mai jos aș dori să mă concentrez asupra mai multor caracteristici de copiere a copiilor de rezervă folosind QMB:

1. Frecvența copierii este determinată de programul de script care conține sarcina „Copiere copii de arhivă”. O sarcină poate fi plasată într-unul sau mai multe scenarii.
2. Sunt copiate doar fișierele de rezervă noi și modificate - acest lucru reduce sarcina în rețea și vă permite să efectuați copiere frecventă. De exemplu, puteți copia de fiecare dată după crearea unei noi copii de rezervă a jurnalului de tranzacții.
3. Pentru un folder de rețea, puteți seta perioada de păstrare a fișierelor. Astfel, pe disc local SQL Server poate stoca copii de siguranță, de exemplu, 1 săptămână și în folderul de rețea in 1 luna.
4. Este posibil să configurați copierea de rezervă numai pentru bazele de date de politici selectate.

Recuperarea bazei de date

Comanda „Restaurare din copie de rezervă” vă permite să:

• Restaurați o bază de date din backup-uri la un anumit moment în timp cu selectarea automată a unui lanț de backup-uri (dacă backup-urile au fost create pe același server SQL).
• Restaurați o bază de date dintr-un fișier de rezervă complet.
• Restaurați copiile de siguranță ale unei baze de date într-o altă bază de date, inclusiv una nouă.
• Efectuați o verificare a integrității bazei de date după ce a fost restaurată.

Alerte prin e-mail

Sarcină în curs de desfășurare:
„Database Workers.NestedPlan_1” a început la 19.05.2015 17:00:00
DURATĂ:
0 oră, 0 minut, 5 sec.
STAT:
Eroare
MESAJE:
Sarcina nu a fost finalizată. Sarcina a fost lansată de Schedule 9 (MaintenancePlan). Ultimul pas efectuat a fost Pasul 1 (Copia de rezervă a jurnalului de tranzacții).

Spre deosebire de Database Mail, QMB trimite primele 15 rânduri de text de eroare din notificare. De obicei, acest lucru este suficient pentru a înțelege motivul și pentru a lua măsuri. acțiunile necesare. Puteți vizualiza jurnalul complet în jurnalul de întreținere al programului. Exemplu de mesaj de eroare:

Scenariul „Taricuri intensive în resurse pentru baze de date OLTP medii (în fiecare noapte)” a fost executat cu erori pe serverul „Srv05”.

Început scenariu: 06.06.2015 1:00
Sfârșit lucrări: 06.06.2015 1:29
Durata: 00:29:28

Total sarcini: 7
Sarcini finalizate: 7
Cu erori: 1

1. Sarcina „Recuperare din copiile de rezervă într-o bază de date temporară cu verificarea ulterioară a integrității” (bază de date: IPGor)
Mesaj: 4305, Nivel: 16, Stare: 1, Linie: 21
Jurnalul din acest set de rezervă începe cu LSN 5235000000291100001, care nu poate fi încă aplicat bazei de date. O copie de rezervă anterioară a jurnalului care include LSN 5228000000281600001 poate fi restaurată.

Mesaj: 3013, Nivel: 16, Stare: 1, Linie: 21
RESTORE LOG a fost anulat cu o eroare.

Mesaj: 50000, Nivel: 16, Stare: 1, Linie: 119
A apărut o eroare în timpul procesului de recuperare

Există, de asemenea, un mecanism de prevenire a trimiterii cantitate mare litere identice, de exemplu, dacă eroarea se repetă în mod regulat.

Politica de licențiere și costuri

Licențele sunt eterne și nu sunt limitate în timp. Dacă este necesar, licența poate fi transferată cu ușurință de la un server la altul.

Sprijin
Din momentul în care achiziționați o licență comercială, puteți lansa orice actualizări de program timp de 1 an pentru a instala actualizările ulterioare, va trebui să extindeți suportul.

Concluzie

Sper că ați găsit această recenzie utilă. Amintiți-vă că performanța slabă și opririle bruște ale SQL Server dăunează reputației întregii organizații IT, în timp ce pierderea datelor în majoritatea cazurilor duce la consecințe și mai grave. Dacă ați creat un plan de întreținere, dar nu aveți încredere în fiabilitatea acestuia, atunci vă aflați pe o bombă cu ceas - vă sfătuiesc cu insistență să preveniți o urgență în avans, mai degrabă decât să vă ocupați de consecințele acesteia.

Vă mulțumesc pentru atenție, sunt gata să vă răspund la întrebări în comentarii.

Etichete: Adăugați etichete

Acest articol m-a determinat să scriu o problemă pe care am rezolvat-o recent pentru unul dintre clienți.

Mai exact, au existat chiar mai multe probleme care, ca de obicei, au fost stratificate una peste alta (sau au fost „stratificate” de către administratori care încercau să rezolve problema).
Articolul nu își propune să ofere o descriere cuprinzătoare și detaliată a întregului sistem Service Broker, cu toate capabilitățile acestuia.
Aceasta este doar o descriere a mediului pe care l-am întâlnit cel mai frecvent când am rezolvat probleme.
Probabil toți cei care citesc acest blogștiu ce este Service Broker în SQL Server, dar pentru a începe cu un punct de plecare, voi spune câteva cuvinte despre acest lucru.

Această caracteristică utilă a apărut pentru prima dată în SQL Server 2005 și nu s-a schimbat prea mult de atunci. Mai exact, a crescut cu unele capacități noi, dar principiile stabilite în acei ani au rămas neschimbate.
Aşa.
După cum urmează de la https://technet.microsoft.com/ru-ru/library/ms166049(v=sql.105). aspx, Service Broker vă ajută să creați aplicații asincrone, slab cuplate, în care componentele independente lucrează împreună pentru a îndeplini o sarcină. Aceste componente fac schimb de mesaje care conțin datele necesare pentru a finaliza o sarcină. Această secțiune descrie următoarele aspecte ale Service Broker:
dialoguri;

• eficientizarea și coordonarea mesajelor;
• programare asincronă bazată pe tranzacții;
• suport pentru aplicații slab cuplate;
• componente ale componentei Service Broker.

Principalele componente ale sistemului sunt:

• Mesaje. Blocuri de informații schimbate între participanți.
• Contracta. Mesajele sunt colectate într-un contract, astfel încât schimbul de mesaje să fie mai formalizat.
• Cozile. Mesajele care urmează să fie trimise și primite sunt plasate în cozi speciale pe care le au atât expeditorul, cât și destinatarul.
• Serviciu. Toate componentele de mai sus sunt conectate printr-un serviciu, care este unitatea de interacțiune în sistem.
• Trasee. Pentru a livra mesaje către servicii, sunt create rute de livrare.
• Dialog. O modalitate programabilă de a trimite un mesaj de la un inițiator la un destinatar și înapoi.
• Tranzacții. Toată prelucrarea datelor în timpul transmiterii și primirii se efectuează conform principiului tranzacțional, excluzând pierderea datelor.

Mediul meu de testare include:

• Două instanțe de SQL Server instalate pe diferite mașini virtuale
• Controler de domeniu.
• Punctele finale sunt configurate pentru a utiliza autentificarea Windows.
• Utilizatorii fără autentificare sunt creați pe ambele servere, folosind certificate pentru autentificare reciprocă.
• Certificatele au fost copiate pe ambele servere folosind backup.

Cum funcționează totul împreună. Mai jos este o diagramă simplificată de mesagerie și descrierea acesteia.

1. Când este trimis de la inițiator, mesajul ajunge în coada de transmisie internă, care este o tabelă de sistem internă sys.sysxmitqueue Prin executarea unei cereri către acesta, vom obține ceea ce ne așteptam.

Pentru a vizualiza mesajele care sunt în coadă, acestea sunt „expuse” în exterior vedere dinamică sys.transmission_queue rulând o interogare la care veți obține aproape același rezultat. Cu toate acestea, în această viziune există o foarte element util, aceasta este coloana transmisie_status care conține informații despre o eroare care a apărut în timpul transmiterii și procesării mesajului.
De exemplu: " Încercarea de conectare a eșuat cu eroarea: „10061 (Nu s-a putut realiza nicio conexiune deoarece mașina țintă a refuzat-o în mod activ.)“.”
Mesajul este înregistrat și în jurnalul de tranzacții, ceea ce asigură procesarea tranzacțională a acestuia.

Toate mesajele din toate serviciile create trec prin acest tabel intern și, în consecință, prin vizualizare, iar dacă nu există erori, sunt transmise în continuare. Mesajele pot fi criptate folosind certificate înainte de transmitere. Dacă mesajele vor fi criptate sau nu, depinde de setările dialogului care inițiază conexiunea.
2. După ce mesajul este plasat în coada de transmisie (sys.transmission_queue), se realizează clasificarea acestuia.
Esența clasificării este de a determina unde se află serviciul căruia îi este adresat acest mesaj. Pentru a determina direcția de transmisie, sunt utilizate rutele de livrare create în timpul etapei de implementare a serviciului. ÎN în acest caz, sunt configurate două rute. Unul indică un serviciu de consum la distanță, celălalt indică o instanță locală SQL Server pentru a furniza alerte locale.

Putem vedea pasul de clasificare rulând folosind urmele SQL Profiler dacă selectăm evenimente legate de Service Broker. Vă rugăm să rețineți că unele dintre evenimentele legate de Service Broker se află în secțiunea Audit de securitate.

3. După clasificarea mesajului, se stabilește o conexiune cu un punct de conectare la distanță (ca în acest caz) (Endpoint). În acest caz, acesta este un server care utilizează protocolul TCP, cu numele SQL2014-I1 și numărul portului (Endpoint) 4022. Dacă apare o eroare în timpul conexiunii, aceasta va apărea în urmărire (așa cum se arată mai jos) și în transmisia_status coloana vizualizării sys.transmission_queue.

4. În următoarea etapă, mesajul este trimis serviciului de către destinatar și confirmat de partea care o primește. Dacă interogați vizualizarea transmission_queue din partea de jos, va returna un rezultat gol, deoarece toate datele din coada expeditorului au fost transferate.

În urma de pe inițiator și expeditor vom vedea confirmarea transferului.

5. Deoarece mesajul a fost livrat destinatarului, acesta ar trebui să apară în coada de intrare a destinatarului.

În continuare, serviciul țintă trebuie să citească mesajele din coadă (de preferință unul câte unul) și să trimită confirmarea de primire inițiatorului dialogului. Această procedură se face folosind o sintaxă specială, care se află în scripturile atașate https://technet.microsoft.com/en-us/library/bb839483(v=sql.105).aspx.
Pe măsură ce datele sunt citite din coadă, acestea devin goale, iar mesajele de confirmare sunt trimise expeditorului (sau nu) sub forma căreia, și dacă sunt trimise sau nu, depinde de dezvoltatorul serviciului.
Dacă mesajele de confirmare sunt programate pentru a fi trimise pe măsură ce coada este citită, atunci acestea urmează aceeași cale ca de la destinatar, doar în ordine inversă.
În acest blog, am examinat în detaliu întreaga cale de la expeditor la destinatar, iar în blogul următor vom începe să luăm în considerare problemele legate de rezolvarea problemelor cu Service Broker la fiecare etapă de procesare și transmitere.

Alexander Kalenik, inginer principal de teren (PFE), MSFT (Rusia)

Deci, continuând subiectul deservirii bazelor de date 1C, să aruncăm o privire mai atentă asupra sistemului de control baze de date relaționale Date Microsoft SQL Server. Acest produs ne oferă capabilități excelente pentru procesarea, stocarea, copierea de rezervă și restaurarea bazelor de date. Voi începe o serie scurtă de articole dedicate acestui subiect. Tot ce este scris mai jos este o părere personală această problemăși este supus criticii.

Acest articol discută despre procesul de creare a planurilor de întreținere de bază. Vom lua în considerare notificarea operatorului, precum și un exemplu de restaurare a bazei de date, în articolele următoare.

În laboratorul de teste avem următoarele:

• Server Windows Server 2008 Întreprindere: SRV-1C-TEST.
• Microsoft SQL Server 2008: SRV-1C-TEST.
• Baza de testare Buh Firma.

Ca de obicei, ne-am propus sarcina:

Efectuați întreținerea de bază între 00:30 și 01:00, iar întreținerea nu ar trebui să fie vizibilă (sau abia observată) pentru utilizatorii de bază.

Să începem cu puncte importante. Baza de date MS SQL poate avea unul dintre cele trei tipuri de model de recuperare:

• Simplu.
• Deplin.
• Cu înregistrare incompletă.

De asemenea, atunci când facem backup, ni se oferă trei opțiuni de copiere din care să alegem:

• Complet.
• Diferenţă.
• Copierea jurnalului de tranzacții (jurnalele).

La versiunea completă copierea salvează baza de date mdf și jurnalul de tranzacții. O copie de rezervă diferențială (cunoscută și sub denumirea de diferențială) copiază datele care s-au modificat de la crearea ultimei copii de siguranță completă. Copierea unui jurnal de tranzacții, în consecință, salvează doar jurnalul de tranzacții în sine.

Dacă selectați modelul simplu, puteți restaura baza de date din ultimul backup diferențial sau complet. Atunci când alegem modelul de recuperare completă, putem restaura baza de date până la un minut creând o copie de rezervă completă, de exemplu, noaptea, și creând copii ale jurnalului de tranzacții în timpul zilei. Mai jos vom vedea unde apare acest punct. De asemenea, aș dori să citez câteva fragmente din MSDN: „Modelul de recuperare în jurnal în bloc este destinat exclusiv ca o completare la model recuperare completă. ÎN caz general Modelul de recuperare în jurnal în bloc este similar cu modelul de recuperare în jurnal complet, cu excepția faptului că majoritatea operațiunilor în bloc sunt înregistrate minim.”

Puteți vizualiza modelul de recuperare al bazei de date accesând, de exemplu, proprietățile bazei de date Buh Firmași mergând la linia - Parametri.

În MSSQL 2008, modelul implicit de recuperare în bazele de date create este Deplin.

Cum să alegi un model de recuperare? Trebuie doar să răspundem la întrebarea: este pierderea de informații fatală în timpul scurs după o copie de rezervă completă? Dacă răspunsul este da, atunci alegeți modelul de recuperare completă dacă nu, alegeți cel simplu. Modelul de înregistrare în bloc ar trebui utilizat numai în timpul operațiunilor masive de baze de date.

Astfel, dacă ai ales model simplu, atunci veți putea restaura datele numai în momentul efectuării backupului complet sau diferențial pe noapte, iar după aceea utilizatorii vor restaura manual toate informațiile. Atunci când alegeți modelul complet, trebuie să faceți o copie de rezervă a jurnalului de tranzacții, altfel jurnalele vor crește semnificativ. Cu orice model de recuperare, ar trebui să aveți întotdeauna o copie de rezervă completă.

În primul rând, vom crea un plan de întreținere de bază pe noapte, care va include secvența următoarelor acțiuni:

• Verificarea integrității bazei de date
• Reconstruirea indexului
• Actualizați statisticile
• Ștergerea cache-ului procedural DBMS
• Backup baze de date
• Curatenie dupa service
• Stergerea jurnalului

Pentru a face acest lucru, conectați-vă la serverul MSSQL utilizând mediul Microsoft SQLServer Management Studio. Puteți începe mediul mergând la Start - Toate programele - Microsoft SQL Server 2008.

Să ne conectăm la serverul SQL și să mergem la Management - Planuri de service. Faceți clic dreapta pe Planuri de servicii și selectați Creați un plan de servicii. Să-i dăm un nume: SRV1CTEST.

În fața noastră se află fereastra SRV1CTEST, în care vom crea secvența de acțiuni indicată mai devreme. Îl vedem imediat apărând Planul_imbricat1. În dreapta numelui planului imbricat veți vedea o pictogramă în formă de semn. Faceți clic pe el și intrați în proprietățile programului de sarcini. Aici puteți schimba numele planului imbricat, puteți seta frecvența de repetare la Zilnicși setați ora. Și așa că acum rămâne să ne umplem planul cu sarcini. Pentru a face acest lucru, din Bara de instrumente, care se află în partea dreaptă, trageți sarcinile.

Să începem cu Verificări ale integrității bazei de date.

După ce ați tras sarcina, faceți dublu clic pe ea. Se va deschide o fereastră în care în linia Bază de date selectăm baza de date creată Buh Firma. Apoi, adăugați sarcini în același mod Reconstruirea indexuluiŞi Actualizați statisticile, fără a uita să selectați în ele baza de date dorită.

Procedură Reconstruirea indexului recreează indexul cu un nou factor de umplere. Datorită acestui fapt, creștem performanța muncii în baza de date.

Sarcină Actualizați statisticile Actualizează informațiile de date din tabel pentru MS SQL. Ceea ce îmbunătățește și productivitatea. Dar după această operație este necesar să ștergeți memoria cache.

Să ne oprim pentru moment și să vorbim despre configurarea conexiunilor între sarcini. Conexiunile reflectă secvența execuției. Pentru a realiza o conexiune între sarcini, trebuie să faceți clic o dată pe sarcină și veți vedea o săgeată. Ea trebuie să fie târâtă la următoarea sarcină. Conexiunea poate avea 3 culori: albastru, verde și roșu, fiecare dintre acestea înseamnă trei tipuri de tranziție: după simpla finalizare a sarcinii anterioare - Finalizare, în caz de finalizare cu succes - Succesși dacă apare o eroare în timpul executării sarcinii anterioare - Eroare. Puteți vedea toți acești parametri făcând clic dreapta pe săgeata desenată între sarcini. Astfel, dacă avem nevoie Reconstruirea indexului concediat numai după finalizarea cu succes a sarcinii Verificarea integrității bazei de date, trebuie să le conectăm cu o săgeată. Făcând clic dreapta pe săgeată, schimbați modul în Cu succes După cum vedem, culoarea sa s-a schimbat în verde.

Pe în acest moment avem 3 sarcini create în planul nostru imbricat. După cum probabil ați observat, sarcina de golire a cache-ului procedural DBMS nu se află în bara de instrumente. Vom folosi problema Execuţie Instrucțiuni T-SQL . Să-l glisăm în plan și să facem dublu clic pe el. Vedem o fereastră în care introducem următoarele:

23/09/2015

Erori tipice în configurarea planurilor de întreținere pentru MS SQL Server DBMS pentru 1C

Bună ziua, colegi.

În articolul de astăzi am dori să luăm în considerare un subiect destul de popular și popular, cum ar fi configurarea planurilor de întreținere pentru MS SQL Server. În p ca urmare a auditurilor noastre, noirezidual frecvente (mai mult de 60% din cazuri)Descoperim inexactități în configurația SGBD-ului MS SQL Server folosit pentru a lucra cu produsele 1C. Practica arată că acest SGBD este cel mai comun, așa că în acest articol vom lua în considerare principalele nuanțe ale lucrului cu el.

Deci, de unde începeți să stabiliți un plan de întreținere? De la o copie de rezervă, desigur! Prima regulă a DBA este: „Nu începeți să faceți nimic fără o copie de rezervă”. Ei bine, nici noi nu vom face. Să ne uităm la două opțiuni principale pentru crearea de copii de rezervă, sau mai degrabă două modele de rezervă sau modele de recuperare ( https://msdn.microsoft.com/ru-ru/library/ms189275(v=sql.120).aspx )

Recuperare folosind modelul simplu

Baza de date este în modul de recuperare SIMPLU. Ce înseamnă acest lucru? Aceasta înseamnă că există doar copii de rezervă complete, nu este nevoie să faceți copii de rezervă ale jurnalelor de tranzacții, performanța în acest sens este maximă, dar puteți restaura doar în punctul de backup. Restaurarea bazei de date „la un anumit moment în timp” este imposibilă.
Prin urmare, în fiecare seară (sau mai des, în funcție de nevoie) trebuie să luăm o copie nouă a bazei noastre de date și să o punem într-un loc sigur și cu siguranță nu în același loc cu baza noastră de date principală.
În general, utilizarea modelului SIMPLE pentru baze de lucru reale este justificată doar în cazurile în care sarcină mareși nesemnificația evenimentului de pierdere a datelor de la ultima copie de rezervă.

În plus, voi aborda imediat problema lucrului cu jurnalul de tranzacții. Deoarece jurnalul de tranzacții nu ne este foarte util în acest mod de recuperare, nu este nevoie să îl faceți o copie de rezervă - toate informațiile din jurnal au fost deja transferate în backup. De obicei, jurnalele din acest model de recuperare nu vor crește mult, dar uneori este util să-l trunchiați. De exemplu, după o schimbare masivă a datelor, această operațiune poate fi extrem de benefică în ceea ce privește spațiul de jurnal de tranzacții. Dacă discul cu jurnalul devine plin, sunteți garantat că aveți probleme cu funcționarea bazei de date.

Trunchierea datelor poate fi efectuată fie folosind vrăjitorul standard de configurare a planului de servicii, fie folosind un script T-SQL simplu:

DBCC SHRINKFILE(DatabaseName, 1);
MERGE

Acest script va reduce dimensiunea fișierului jurnal al bazei de date la dimensiunea de pornire(în mod implicit, cel mai adesea acesta va fi de 1 MB). Cu toate acestea, nu trebuie să efectuați această operație în mod constant. În mod ideal, fișierele dvs. nu ar trebui să își schimbe dimensiunea în timpul lucrului sistematic, dar vom vorbi despre asta altădată.

Recuperare folosind modelul complet

Să ne uităm la principiile de bază ale instalării backupului și gestionării dimensiunii jurnalului de tranzacții din punctul de vedere al celei mai răspândite opțiuni - modelul complet de recuperare a bazei de date.

Model complet recuperarea diferă de recuperarea simplă prin aceea că pe parcursul întregii funcționări a bazei de date putem (sau, mai precis, TREBUIE!) să facem copii de rezervă ale jurnalului de tranzacții, oferind astfel posibilitatea de a restaura baza de date între punctele principalelor backup-uri sau rollback-uri pentru anumite perioade de timp de funcționare a bazei de date, precum și asigurarea eliberării spațiului în fișierul jurnal (truncare). Dacă nu se face acest lucru, va crește continuu până când într-o zi va umple tot spațiul disponibil (fie pe disc, fie până la limita stabilită în SGBD). Consecințele par evidente, și nu cele mai plăcute.

Din punctul de vedere al unor copii de rezervă complete, desigur, limita minimă este de obicei aceeași într-o zi. Backup-urile diferențiale ale bazei de date sunt capacitatea de a salva numai modificările care au avut loc de la ultima copie de rezervă. Acest lucru vă permite să faceți o copie de rezervă rapidă și eficientă a bazei de date, folosind în același timp suficient recuperare rapidă DB la starea dorită.
Backup-urile jurnalului de tranzacții pot fi efectuate ori de câte ori aveți nevoie pe parcursul zilei, mai precis decât backup-urile diferențiate ale bazei de date. Vă recomandăm să selectați de obicei un nivel de detaliu al copiei de aproximativ ¼ din timpul necesar pentru a crea copii diferențiate ale bazei de date.

După cum sa menționat mai sus, atunci când efectuați o copie de rezervă a jurnalului de tranzacții al bazei de date într-un model complet, acesta va fi trunchiat automat (numai că nu confunda trunchierea cu compresia!).

Recalcularea statisticilor și lucrul cu indici

Practica actuală de lucru cu indici și statistici în rândul clienților noștri este destul de eronată. De foarte multe ori ne confruntăm absență completă aceste proceduri în planurile de întreținere a bazei de date. Ele sunt adesea făcute în ordine greșită. Adesea pur și simplu nu este optim (de exemplu, în același timp!).

Secvența corectă de acțiuni arată astfel:

Determinarea gradului de fragmentare a indexului

Dacă indicele este mic sau ușor fragmentat, lansăm procedura de reorganizare a indicelui și recalculare a statisticilor.

În caz contrar, începem procedura de reconstrucție a indexului. Procedura de reconstrucție a indexului va actualiza efectiv statisticile, deci nu este nevoie să recalculăm statisticile după o reconstrucție completă a indexului.

1. Recalculăm toate celelalte statistici acolo unde este necesar.

Dacă luăm în considerare un mini-script pentru recalcularea statisticilor și reconstruirea indicilor (nu ne pretindem a fi super complet și universal), atunci va arăta cam așa (cu indici sortați printr-un cursor):

DECLARE @SQL NVARCHAR(MAX)

DECLARE @MIN_IND_SIZE întreg = 128

DECLARE @MIN_FRAGMENTATION_LEVEL întreg = 10

DECLARE @CRITICAL_FRAGMENTATION_LEVEL întreg = 30

DECLARE currentIndex CURSOR LOCAL READ_ONLY FORWARD_ONLY FOR

SELECTAȚI „ALTER INDEX [” + ind.name + N”] ON [” +

SCHEMA_NAME(obj.) + "].[" + obj.name + "] " +

CAZĂ CÂND stat.avg_fragmentation_in_percent > @CRITICAL_FRAGMENTATION_LEVEL

APOI „RECONSTRUIȚI CU (SORT_IN_TEMPDB = ON, ONLINE = ON)”

ALTE „REORGANIZAȚI”

END + ";"

DIN(

SELECT stat., stat.index_id,

avg_fragmentation_in_percent = MAX(stat.avg_fragmentation_in_percent)

FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, "DETAILED") stat

UNDE stat.page_count > @MIN_IND_SIZE AND stat.index_id > 0

ȘI stat.avg_fragmentation_in_percent > @MIN_FRAGMENTATION_LEVEL

GROUP BY stat., stat.index_id

) stat

JOIN sys.indexes ind WITH(NOLOCK) ON stat. = ind.

ȘI stat.index_id = ind.index_id

JOIN sys.objects obj WITH(NOLOCK) ON obj. =stat.

DESCHIDERE currentIndex

FETCH NEXT FROM currentIndex ÎN @SQL

ÎN CÂT timp ce @@FETCH_STATUS = 0 ÎNCEPE

printează @sql

EXEC sys.sp_executesql @SQL

FETCH NEXT FROM cur ÎN @SQL

ÎNCHIDE currentIndex

DEALLOCATE currentIndex

Vă rugăm să rețineți utilizarea tempdb, precum și păstrarea indexului disponibil în timpul reconstrucției - în funcție de ediția SGBD-ului dvs. ultima functie este posibil să nu fie disponibilă.

Notificări

Pe lângă toate aspectele tehnice, este foarte corect să setați planuri de întreținere care, dacă sunt executate incorect, vă vor anunța în continuare despre o problemă apărută. Și acesta va fi cel mai scurt paragraf din articolul meu. :)

Dacă totul vi s-a părut prea complicat sau nu sunteți sigur că puteți face singur astfel de setări, nu ezitați să ne contactați - vă vom ajuta!