Salutări, dragi cititori.

Destul de recent, a trebuit să refac baza de date 1C Enterprise 8 după o blocare care a avut loc în timpul unei actualizări de configurare. Mai mult, a fost de două ori și metodele folosite în timpul restaurării au fost și ele diferite (veți afla în curând de ce). În acest articol vreau să vorbesc despre metodele pe care le-am folosit.

Toate metodele luate în considerare în articol se referă la versiunea de server a operațiunii „1C Enterprise 8”, utilizată de DBMS - MS SQL 2005.

Cazul numărul 1.

La actualizarea configurației a apărut eroarea „Conflict de blocare”, configuratorul a fost închis. Când am încercat să intru din nou în configurator, am primit o eroare: Atenție !!! A apărut o eroare la reîmprospătarea datelor de la ultima restructurare. Doriți să reîncercați actualizarea?" "Nu chiar"

Cu un răspuns pozitiv, a fost emis următorul mesaj A fost detectată o operație de salvare a configurației incomplete. Pentru a continua lucrul, trebuie să finalizați operația.”

Căutările pe Internet au dat următoarea metodă. In masa Config din baza noastră de date, trebuie să ștergeți liniile în care câmpul FileName = commit sau FileName = dbStruFinal sau FileName = DynamicallyUpdated (pentru 8.3) sau FileName = dynamicCommit (8.3)și, de asemenea, ștergeți masa ConfigSave... Permiteți-mi să explic de ce sunt responsabile datele din tabel: Config - acest tabel stochează configurația bazei de date, ConfigSave - acest tabel stochează configurația de lucru, de exemplu. înainte de a apăsa butonul F7în configurator.

Deschideți SQL Serger Managment Studio și deschideți fereastra de interogare făcând clic pe butonul „ Interogare nouă»Deschide o fereastră de interogare.

În fereastra de solicitări, scrieți cereri și executați-le:

1. ștergeți din [OurBaseName] .. unde FileName = „commit”
2. ștergeți din [OurBaseName] .. unde FileName = ‘dbStruFinal’
3. ștergeți din [OurBaseName] .. unde FileName = „DynamicallyUpdated” (pentru versiunea 8.3)
4. ștergeți din [OurBaseName] .. unde FileName = „dynamicCommit” (pentru versiunea 8.3)
5. ștergeți din [OurBaseName] ..

După finalizarea acestor solicitări, configuratorul a pornit fără probleme.

Cazul numărul 2

Motivul erorii de intrare în configurator este același ca în primul caz: un conflict de blocare la actualizarea configurației.

Ștergerea rândurilor dintr-un tabel Configși curățând masa ConfigSave ajutat parțial: configuratorul s-a deschis, dar nu a funcționat în întreprindere formulare gestionate.

În acest caz, mi-au venit în minte 2 căi de dezvoltare:

1. Recuperarea din arhivă. În această versiune, a existat un mare „DAR”: s-a întâmplat ca arhiva să fie creată după actualizare, adică. arhiva era cu o eroare.
2. A existat o idee de a folosi configurația unei baze de date distribuite, care nu a fost actualizată, deoarece fișierul pentru schimb era cu o eroare.

A fost aleasă a doua opțiune pentru a rezolva problema. În continuare, vă voi spune pas cu pas ce am făcut.

1. Deschideți SQL Serger Managment Studio și creați o bază de date arbitrară, de exemplu Perenos.În această bază de date, creăm un tabel Config. Cine nu știe sql pentru transferul de date de la un tabel la altul, atunci MS SQL are un serviciu minunat " Expertul de import și export SQL Server". Cu acest serviciu, puteți transfera cu ușurință date dintr-o bază de date în alta. Pentru a porni acest serviciu, trebuie să apăsați butonul „ ctrl + r„Și în caseta de dialog scrieți comanda” dtswizard «.
   
2. Transferăm folosind serviciul dtswizard date din tabel Config baza noastră de date la tabel Config baza Perenos.
3. Curățând masa Configîn baza noastră de date folosind o solicitare ștergeți din [OurBaseName] ..
4. Pe serverul unde se află baza de date distribuită, pornim serviciul dtswizardși transferați date din tabel Config la același tabel numai în baza noastră de date.

Cu ajutorul unor astfel de acțiuni, s-a dovedit rapid și cu un timp de nefuncționare minim pentru a restabili baza de date să funcționeze.

Preistorie.

Acum două zile, am trecut de la 8.1 la 8.2 - am schimbat confa UPP 1.2 ... la 1.3.22.1. În consecință, o grămadă de diferențe față de configurația tipică care a apărut - a implicat o grămadă de erori. Timp de două zile, fără să petrecem noaptea, schimbăm configurația non-stop. Configuratorul este salvat de 15 ori pe oră. Era de așteptat ca la salvare, configurația să se prăbușească, ceea ce sa întâmplat de fapt. Astfel de probleme, în conf 8.1, erau întotdeauna rezolvate prin deconectarea utilizatorilor care încă lucrau în baza de date, dar nu se mai puteau conecta din nou cu acces exclusiv. În noua noastră configurație 8.2, baza ne-a spus „Sunt obosit. Plec”), în general, problema este descrisă în anunț.

Ce s-a făcut bine și greșit. Și sfaturi despre ce să faci mai întâi.

În primul rând, în frământări, începem să căutăm modalități de a rezolva problema pe Internet. Google dă literalmente 3 articole în acest moment pe textul erorii care apare. Le voi enumera.

În general, în toate cele trei articole, răspunsul la soluția la problema actuală este același - „Restaurați baza de date dintr-o copie de rezervă”.

Nu este nevoie să vorbim despre importanța copiilor de rezervă a regularității lor și așa mai departe. Cred că în ceea ce privește noi, acesta a fost un avertisment bun, deși am avut o copie de rezervă a bazei de date după ce a fost salvată în configurația 1.3, dar puțini oameni își urmăresc regularitatea și faptul că sunt gata (și hard disk-ul nu este curățat etc.). În consecință, iertați „evidența căpitanului”, dar dacă aveți o copie de rezervă proaspătă, în primul rând, și începeți să restaurați baza de pe aceasta, nu pierdeți timp prețios, pentru care conducerea nu vă va mulțumi pentru timpul de nefuncționare. Cu toate acestea, puteți încerca să reînvie baza „căzută”, care, datorită persistenței mele, a fost întreprinsă. Aș dori să notez că și alți programatori au încercat să revigoreze cumva baza folosind metodele 1c, dar nu au avut succes. Nu știu tot ce a făcut, dar am văzut încercări de a lansa 1C în modul comandă imediat odată cu lansarea Testării și repararea securității informațiilor, care de fapt nu a pornit nimic.

Mi-am concentrat atenția pe SQL. Sunt familiarizat cu puțină experiență în configurarea și administrarea bazelor de date și a unui set tipic de comenzi sql, dar metoda descrisă mai jos nu necesită cunoștințe și abilități profunde de lucru cu SQL. Tocmai am conectat logica - dacă baza de date a „căzut” în momentul salvării configurației, ajungem la concluzia că structura unui tabel s-ar fi putut prăbuși în SQL (deși nu știam înainte că configurația din versiunea 8 era într-o singură continuare). tabel) și acest tabel în care este stocată configurația de bază. și tabelul numit dbo.config. Ulterior am aflat prin metoda „proastă” și iarăși logică, pentru că singurul lucru pe care l-am găsit a fost o dezvoltare locală, care nu m-a ajutat ci mai degrabă utilă pentru viitor și anume, Mulțumesc autorului din contul colegului meu, cu ajutorul căruia l-am descărcat. Așa că mă întorc la cel mai important lucru - încercările (!) de a restabili baza de date pentru că, din păcate, nu vă pot oferi nicio garanție și există o serie de presetări pe care este posibil să nu le aveți sau, după cum se spune, aceasta nu este cazul tau ...

Cerințe și restaurarea bazei de date în sine.

(Atenție. Asigurați-vă că vă uitați la nota de subsol de mai jos dacă doriți să încercați să reînviați configurația în sine. Azi (18.04.2012) am reușit să o fac prin experimente pentru că mi-a părut rău pentru munca săptămânală care s-a făcut la ea . Astfel, s-a dovedit a revigora baza lăsând vechiul configurator fără copii)

Date inițiale - baza SQL 1C 8.2, configurația UPP 1.3.22.1 (cred că metoda descrisă este potrivită pentru orice set de bază 8.2). SQL Server 2005. Eroarea este descrisă în anunț și eroarea a apărut la momentul salvării configurației! Cea mai importantă și obligatorie cerință !!! O copie a bazei de date SQL cu ACEEAȘI CONFIGURARE (!) Am configurat schimbul automat cu o altă bază de date și configurațiile lor sunt aceleași. În plus, deoarece suntem trei programatori 1C, fiecare are un fișier de configurare descărcat și relativ proaspăt. De fapt, orice bază de date este potrivită, indiferent de ce date, principalul lucru este că configurația din ea corespunde structurii metadatelor bazei de date. Voi remarca faptul că configurația era chiar puțin diferită de cea cu care a decolat baza. Cea mai de bază, în opinia mea, este cerința ca diferențele de configurare să nu afecteze metadatele. Nu uitați de faptul că dacă configurația este diferită, atunci în final veți obține o bază de lucru dar cu configurația din copia dvs.

Procesul de recuperare în sine nu vă va lua mult timp - doar câteva minute, dar vă recomand cu căldură să faceți în prealabil o copie de rezervă chiar și a bazei de date „căzute”, deoarece poate dura timp. De exemplu, veți putea restaura baza de date derulând înapoi din fișierul jurnal (pe care, din păcate, l-am „cras” în forfota recuperării) sau o altă metodă. Deci, permiteți-mi să vă reamintesc că undeva trebuie să existe o bază de date SQL, indiferent de date, dar cu aceeași configurație. Dacă configurația dvs. este o configurație tipică „neatinsă” (ceea ce înseamnă că această problemă a apărut în timpul rulării unei noi configurații tipice), puteți crea o nouă bază de date goală și o puteți completa cu confa tipică pe care o aveați înainte. Dacă configurația pe care ați găsit-o nu este atât de proaspătă - gândiți-vă și luați o decizie, poate că diferențele cu copia configuratorului, pe care va trebui să o repetați în baza de date, vor necesita mult mai mult timp și resurse decât pierderea informații din baza de date 1C în sine... Un fel de sabie cu două tăișuri) Deci...

1. Facem o copie de rezervă a bazei de date restrânse folosind instrumente SQL.

2. Ștergem tabelul dbo.config din baza noastră de date în care se află configurația ruptă. Acest lucru se poate face din SQL-Profiler, de exemplu, rulând comanda în el:

Șterge din.

unde Base2009 este numele bazei restrânse.

Notă: undeva în rețea am citit informații neverificate, care uneori ajută la ștergerea tabelului dbo.ConfigSave, care se presupune că conține configurația rulată. S-a dovedit a fi gol în baza noastră de date, așa că nu am șters tabelul gol. Poate - puteți înșela și revigora cumva baza 1C folosind acest tabel, dar, neștiind mecanismul de funcționare 1C cu acest tabel, nu voi spune nimic în planul de acțiune în legătură cu acesta.

3. Copiați tabelul din baza de date cu întreaga configurație în baza noastră de date deteriorată. În cazul meu, ambele baze de date erau pe același server, așa că comanda de copiere din SQL-Profiler arăta astfel.

inserați în .. selectați * din ..

unde base2009 este numele bazei restrânse, BaseCopy este numele bazei cu o copie a configuratorului

4. Lansăm 1C, iar dacă reușim, sărim, căci sunt cu bucurie că am reușit să revigorăm baza de date fără nicio pierdere de informații.

5. (Evidență căpitan) verificăm, depanăm și monitorizăm sistemul pentru crearea de copii de siguranță ale bazei de date și abordăm procesul de actualizare a configurației în mod foarte responsabil (facem asta nu prin rețea, ci de preferință pe server, dacă este posibil, făcând o copie de rezervă preliminară). Mai ales dacă versiunea dvs. 1C a devenit 8.2. Din câte am înțeles din articolele de pe rețea și din primele două zile de lucru cu ea, este mai sensibilă și mai capricioasă, față de 8.1 cu care nu au existat astfel de probleme.

5a. Dacă configurația bazei de date din care veți copia tabelul confa este încă diferită (fără a avea diferențe în metadate, despre care am menționat deja), și undeva există fișierul dvs. cf relativ proaspăt cu confa descărcată - rulați-l la baza reînviată . În caz contrar, va trebui să repetați toate diferențele care au fost cu copia configuratorului. Așa că încă o dată gândește-te bine și analizează - ceea ce este mai important - munca ta privind schimbarea configurației (și cât timp vei petrece pe ea) sau munca utilizatorilor bazei de date până la ultima copie de rezervă. În cazul meu, a fost munca a 2 programatori timp de 3 ore față de munca a aproximativ 100 de utilizatori timp de 1,5 zile, așa că alegerea a fost evidentă.

ZY Lasă-mă să-ți amintesc din nou? că această funcție de recuperare este o modalitate nedocumentată de 1C-oaie de a restabili baza (în cazul specific al unui colaps al bazei care a avut loc în timpul salvării confa) și tot ceea ce faci - faci pe propriul risc și risc, dar mai ales în În cazul meu, există și alte modalități de a revigora baza cu minim, nu a existat nicio pierdere de informații existente (fișierul jurnal a fost șters și cea mai recentă copie de rezervă a reprezentat pierderea a 1,5 zile de lucru a aproximativ 100 de utilizatori), prin urmare, după cum se spune. , podurile au fost arse)

ZYY Acesta este primul meu post aici. frecați pe alte forumuri 1C, dar consider această resursă una dintre cele mai utile în ceea ce privește evoluțiile și publicațiile publicate, așa că nu judeca strict pentru multe FI din această publicație). Aș fi foarte fericit dacă aș ajuta cu adevărat pe cineva la restaurarea bazei distruse, pentru că doar un război nuclear este mai rău de atât)

ZYYYY După 3 săptămâni, problema s-a repetat) De data aceasta, a durat câteva secunde să se rezolve (dacă nu ținem cont de timpul creării unei copii de rezervă) și nici măcar utilizatorii nu au trebuit să fie dați afară.

_____________________________________________________________________________________________________________

Un coleg a venit în alergare astăzi. Aceeași necaz. Doar baza este test și nu baza de lucru în sine, iar baza în sine este pentru el în măsura în care - dar configuratorul este important pentru el. Timp de o săptămână și-a petrecut o săptămână peste el, fără a încărca niciodată într-un fișier cf și nu a încărcat modificări în baza de lucru. Ei bine, de ce să nu sapi mai adânc cu masa?! E și mai ușor de data asta. Deschid SQL Managment Studio. Formez o interogare pe tabel pentru câmpurile cu data curentă a modificării și ora la care baza a zburat - rezultatul dă 2 înregistrări. În primul rând - Field FileName = "commit" Ei bine - bang această înregistrare - și totul a funcționat pentru mine! Configuratorul a prins viață și baza funcționează din nou. Ce trebuie făcut ?!

Deci, în fereastra deschisă a SQL Managment Studio, căutăm baza noastră de date - deschideți Tabele, căutați un tabel cu confa la sfârșitul listei dbo.config pe masă - butonul din dreapta - Masă deschisă... Mai departe, în fereastra din dreapta, coborâți în tabel propriu-zis, în ordine alfabetică la câmpul în care FileName = „commit”. Ne aflăm pe această intrare - butonul drept al mouse-ului - Șterge.În general, ștergeți intrarea cu fișierul binar. În continuare, încercăm să mergem la config. Eroarea este aceeași apare prima dată. Probabil că nu a funcționat? O.K... Și apoi, înainte de a emite ca înainte al 2-lea mesaj despre imposibilitatea salvării - computerul s-a gândit la asta. După 30 de secunde - DESPRE MIRACUL! S-a deschis configuratorul. Încercăm să salvăm configuratorul (după salvarea fișierului cf). Configuratorul este salvat. Astfel, lupii sunt hrăniți, iar oile sunt în siguranță. Nu sunt sigur de funcționarea completă a bazei după astfel de abuzuri – așa că v-aș sfătui să restructurați și să recalculați rezultatele mai târziu seara (după ce faceți o arhivă, desigur). Recuperare fericită și emoții pozitive)

Cutie cu nisip

1C, restabilirea configurației bazei de informații folosind MS SQL

La un moment dat m-am confruntat cu o problemă: la actualizarea configurației din depozit, a apărut o eroare și 1C a fost închis.

După cum sa dovedit mai târziu, depozitul de configurare a fost distrus, iar când configurația a fost actualizată, configurația bazei de date a zburat și ea din depozit. O eroare similară a mai apărut cu o actualizare dinamică de securitate a informațiilor.

pentru că Această problemă a apărut de mai multe ori. Am decis să împărtășesc o opțiune de tratament.

La următoarea lansare a configuratorului a apărut o eroare: „Atenție !!! A apărut o eroare la reîmprospătarea datelor de la ultima restructurare. Doriți să reîncercați actualizarea?" dacă răspunsul este da, primim mesajul: „A fost detectată o operație de salvare a configurației incomplete. Pentru a continua lucrul, trebuie să finalizați operațiunea „după care aplicația este închisă.

La analiza acestei probleme au fost găsite mai multe opțiuni pentru a rezolva problema, fiecare soluție funcționând în cazuri diferite.

Opțiunea 1 (dacă aveți o copie de rezervă SQL cu o copie cu o configurație identică):

Se implementează o copie a securității informațiilor și se execută o cerere de următoarea construcție:
UTILIZAȚI GO DELETE FROM .. GO INSERT INTO .. ​​​​SELECT * FROM .. GO
În acest caz, tabelul în care este stocată configurația IB este reumplut. Este recomandabil să testați și să corectați securitatea informațiilor după această operațiune.

Opțiunea 2 (în absența copiei de rezervă):

Această opțiune a fost tratată ca ultima picătură. pentru că configurația era în curs de dezvoltare și backupul a fost puțin uitat, bazându-se pe depozit.
În baza de date, două înregistrări sunt șterse din tabelul „Config” cu valoarea din coloana „FileName” - dbStruFinal și commit

Se execută următoarea interogare:
UTILIZAȚI GO DELETE FROM. WHERE FileName = "dbStruFinal" GO DELETE FROM. WHERE FileName = "commit" GO
Destul de ciudat, baza prinde viață.

Etichete: 1c enterprise 8.2, SQL, restaurare configurație

Acest articol nu este supus comentariilor, deoarece autorul său nu este încă un membru cu drepturi depline al comunității. Veți putea contacta autorul numai după ce acesta va primi

Cutie cu nisip

1C, restabilirea configurației bazei de informații folosind MS SQL

• Microsoft SQL Server,
• Administrarea bazei de date

La un moment dat m-am confruntat cu o problemă: la actualizarea configurației din depozit, a apărut o eroare și 1C a fost închis.

După cum sa dovedit mai târziu, depozitul de configurare a fost distrus, iar când configurația a fost actualizată, configurația bazei de date a zburat și ea din depozit. O eroare similară a mai apărut cu o actualizare dinamică de securitate a informațiilor.

pentru că Această problemă a apărut de mai multe ori. Am decis să împărtășesc o opțiune de tratament.

La următoarea lansare a configuratorului a apărut o eroare: „Atenție !!! A apărut o eroare la reîmprospătarea datelor de la ultima restructurare. Doriți să reîncercați actualizarea?" dacă răspunsul este da, primim mesajul: „A fost detectată o operație de salvare a configurației incomplete. Pentru a continua lucrul, trebuie să finalizați operațiunea „după care aplicația este închisă.

La analiza acestei probleme au fost găsite mai multe opțiuni pentru a rezolva problema, fiecare soluție funcționând în cazuri diferite.

Opțiunea 1 (dacă aveți o copie de rezervă SQL cu o copie cu o configurație identică):

Se implementează o copie a securității informațiilor și se execută o cerere de următoarea construcție:
UTILIZAȚI GO DELETE FROM .. GO INSERT INTO .. ​​​​SELECT * FROM .. GO
În acest caz, tabelul în care este stocată configurația IB este reumplut. Este recomandabil să testați și să corectați securitatea informațiilor după această operațiune.

Opțiunea 2 (în absența copiei de rezervă):

Această opțiune a fost tratată ca ultima picătură. pentru că configurația era în curs de dezvoltare și backupul a fost puțin uitat, bazându-se pe depozit.
În baza de date, două înregistrări sunt șterse din tabelul „Config” cu valoarea din coloana „FileName” - dbStruFinal și commit

Se execută următoarea interogare:
UTILIZAȚI GO DELETE FROM. WHERE FileName = "dbStruFinal" GO DELETE FROM. WHERE FileName = "commit" GO
Destul de ciudat, baza prinde viață.

Etichete: 1c enterprise 8.2, SQL, restaurare configurație

Acest articol nu este supus comentariilor, deoarece autorul său nu este încă cu drepturi depline membru al comunității. Veți putea contacta autorul numai după ce acesta va primi