Lijep pozdrav, dragi čitatelji.

Nedavno sam morao vratiti bazu podataka 1C Enterprise 8 nakon pada koji se dogodio tijekom ažuriranja konfiguracije. Štoviše, to se dogodilo dva puta, a metode korištene tijekom restauracije također su bile različite (uskoro ćete saznati zašto). U ovom članku želim govoriti o metodama koje sam koristio.

Sve metode razmatrane u članku odnose se na poslužiteljsku verziju rada "1C Enterprise 8", koju koristi DBMS - MS SQL 2005.

Slučaj broj 1.

Prilikom ažuriranja konfiguracije generirana je pogreška "Konflikt zaključavanja", konfigurator je zatvoren. Kada sam ponovno pokušao ući u konfigurator, pojavila se greška: Pažnja!!! Došlo je do pogreške prilikom ažuriranja podataka nakon posljednjeg restrukturiranja. Ponovno pokušati ažuriranje?" "Ne baš"

Ako je odgovor bio da, prikazala se sljedeća poruka "Otkrivena je nepotpuna operacija spremanja konfiguracije. Morate dovršiti operaciju da biste nastavili."

Pretrage na internetu dale su sljedeću metodu. Stol Konfiguracija naša baza podataka treba izbrisati retke u kojima je polje Ime datoteke = potvrda ili FileName = dbStruFinal ili FileName=DynamicallyUpdated (za 8.3) ili FileName=dynamicCommit (8.3) i očistiti stol ConfigSave. Dopustite mi da objasnim za što su podaci tablice odgovorni: Config - ova tablica pohranjuje konfiguraciju baze podataka, ConfigSave - ova tablica pohranjuje radnu konfiguraciju, tj. prije nego što pritisnete tipku F7 u konfiguratoru.

Otvorite SQL Serger Management Studio i otvorite prozor upita klikom na " Novi upit» otvara prozor upita.

U prozoru upita napišite upite i izvršite ih:

1. izbriši iz [OurBaseName].. gdje je FileName = 'commit'
2. izbriši iz [OurBaseName].. gdje je FileName = 'dbStruFinal'
3. izbriši iz [OurBaseName].. gdje je FileName = 'DynamicallyUpdated' (za verziju 8.3)
4. izbriši iz [OurBaseName].. gdje je FileName = 'dynamicCommit' (za verziju 8.3)
5. izbriši iz [OurBaseName]..

Nakon izvršenja ovih zahtjeva, konfigurator se pokrenuo bez problema.

Slučaj #2

Razlog greške pri ulasku u konfigurator je isti kao iu prvom slučaju: sukob zaključavanja prilikom ažuriranja konfiguracije.

Brisanje redaka u tablici Konfiguracija i pospremanje stola ConfigSave djelomično pomogao: konfigurator je otvoren, ali poduzeće nije radilo upravljani oblici.

U ovom slučaju, na pamet su mi pala 2 načina razvoja:

1. Oporavak iz arhive. U ovoj verziji postojao je jedan veliki "ALI": dogodilo se da je arhiva stvorena nakon ažuriranja, tj. arhiva je bila u krivu.
2. Postojala je ideja da se koristi konfiguracija distribuirane baze podataka, koja nije ažurirana, jer je datoteka za razmjenu bila s greškom.

Za rješavanje problema odabrana je 2. opcija. Zatim ću vam reći korak po korak što sam napravio.

1. Otvorite SQL Serger Management Studio i napravite proizvoljnu bazu podataka, na primjer Perenos. Napravite tablicu u ovoj bazi podataka konfiguracija Tko ne zna sql za prijenos podataka iz jedne tablice u drugu, onda MS SQL ima prekrasnu uslugu " Čarobnjak za uvoz i izvoz SQL Servera". Pomoću ove usluge možete jednostavno prenijeti podatke iz jedne baze podataka u drugu. Za pokretanje ove usluge pritisnite " ctrl+r" i u dijaloškom okviru napišite naredbu " dtswizard «.
   
2. Prijenos s uslugom dtswizard tablični podaci Konfiguracija našu bazu podataka u tablicu Konfiguracija baze Perenos.
3. Raščišćavanje stola Konfiguracija u našoj bazi podataka s upitom izbriši iz [OurBaseName]..
4. Na poslužitelju na kojem se nalazi distribuirana baza podataka pokrećemo uslugu dtswizard i prijenos podataka iz tablice Konfiguracija u istu tablicu samo u našoj bazi podataka.

Uz pomoć takvih akcija pokazalo se da je baza podataka brzo i uz minimalno vrijeme zastoja vraćena u radnu sposobnost.

Prapovijest.

Prije dva dana napravili smo prijelaz s 8.1 na 8.2 - promijenili smo konfiguraciju SCP 1.2 ... na 1.3.22.1. Sukladno tome, puno razlika u odnosu na tipičnu konfiguraciju koja se smotala - dovela je do puno grešaka. Dva dana, bez noći, non-stop mijenjamo konfiguraciju. Konfigurator se sprema 15 puta na sat. Bilo je za očekivati ​​da bi se prilikom spremanja konfiguracija mogla srušiti, što se i dogodilo. Takvi problemi, u conf 8.1, uvijek su se rješavali odjavom korisnika koji su još uvijek radili u bazi, ali se više nisu mogli ponovno prijaviti s isključivim pristupom. U našoj novoj konfiguraciji 8.2 baza nam je rekla "Umoran sam. Odlazim"), općenito je problem opisan u najavi.

Što je uzeto od dobrog i krivog. I savjet što prvo napraviti.

Prije svega, u naletu počinjemo tražiti načine za rješavanje problema koji se pojavio na Internetu. Google daje doslovno 3 članka u ovom trenutku prema tekstu greške koja se pojavljuje. Navest ću ih.

Općenito, u sva tri članka odgovor za rješavanje trenutnog problema je isti - "Vratite bazu podataka iz sigurnosne kopije."

Nemojte govoriti o važnosti sigurnosne kopije njihove pravilnosti i tako dalje. Mislim da je za nas ovo bilo dobro upozorenje, iako smo imali sigurnosnu kopiju baze podataka nakon spremanja u konfiguraciji 1.3, ali malo ljudi prati njihovu pravilnost i činjenicu da su gotovi (i tvrdi disk nije očišćen, itd.). U skladu s tim, oprostite "kapetanu očitom", ali ako imate svježu sigurnosnu kopiju - prvo što trebate učiniti je vratiti bazu podataka iz nje, nemojte gubiti dragocjeno vrijeme, za što vam uprava neće zahvaliti na praznom hodu. Međutim, možete pokušati oživjeti "palu" bazu, što je, zahvaljujući mojoj upornosti, poduzeto. Napominjem da je i drugi programer pokušao nekako oživjeti bazu na 1c načine, ali nisu uspjeli. Ne znam sve što je učinio, ali vidio sam pokušaje pokretanja 1C u naredbenom načinu rada odmah s pokretanjem Testiranja i popravljanja informacijske sigurnosti, što zapravo nije pokrenulo ništa.

Usmjerio sam pozornost na SQL. Imam malo iskustva u konfiguriranju i administriranju baza podataka i tipičnog skupa sql naredbi, ali dolje navedena metoda ne zahtijeva nikakvo duboko znanje i vještine u radu sa SQL-om. Samo sam povezao logiku - ako je baza "pala" u trenutku spremanja konfiguracije, zaključujemo da bi se struktura jedne tablice mogla srušiti u SQL-u (iako prije nisam znao da konfiguracija u verziji 8 leži u jednoj nastavnoj tablici ) i ovu tablicu u kojoj je pohranjena osnovna konfiguracija. naime tablicu dbo.config. Kasnije sam to naučio metodom "samoprobijanja" i opet logikom, jer jedino što sam našao bio je lokalni razvoj koji mi nije pomogao ali je bio dosta koristan za budućnost, naime Hvala autoru iz mog račun kolege, s kojeg sam ga skinuo. Dakle, prijeđimo na najvažniju stvar - pokušaje (!) Vraćanja baze podataka, jer vam, nažalost, ne mogu dati nikakva jamstva, a postoji niz unaprijed postavljenih postavki koje možda nemate ili, kako kažu, ovo nije tvoj slučaj...

Zahtjevi i obnova same baze podataka.

(Pažnja. Obavezno pogledajte fusnotu ispod ako želite pokušati oživjeti samu konfiguraciju. Danas (18.4.2012.) uspio sam to učiniti kroz eksperimente jer mi je bilo žao tjednog posla koji je obavljen na tome , Tako se pokazalo da je baza oživljena ostavljajući stari konfigurator bez kopija)

Početni podaci - SQL baza 1C 8.2, SCP konfiguracija 1.3.22.1 (vjerujem da je opisana metoda prikladna za bilo koju 8.2 esquel bazu). SQL Server 2005. Greška opisana u obavijesti i greška koja se pojavila u trenutku spremanja konfiguracije! Najvažniji i obavezni uvjet!!! Kopija SQL baze podataka s ISTOM KONFIGURACIJOM(!) Postavili smo automatsku razmjenu s drugom bazom podataka i njihove konfiguracije su iste. Osim toga, budući da smo tri 1C programera, svaki ima neučitanu i relativno svježu conf datoteku. Zapravo, poslužit će svaka baza podataka, bez obzira s kojim podacima, glavno je da konfiguracija u njoj odgovara strukturi metapodataka baze podataka. Napominjem da je konfiguracija bila čak i malo drugačija od one iz koje je baza krenula. Najosnovniji, po mom mišljenju, zahtjev je da razlike u konfiguraciji ne utječu na metapodatke. Ne zaboravite činjenicu da ako je konfiguracija drugačija, tada ćete na kraju dobiti radnu bazu, ali s konfiguracijom iz vaše kopije.

Sam proces oporavka vam neće oduzeti puno vremena - svega par minuta, ali toplo preporučam da prvo napravite sigurnosnu kopiju čak i "pale" baze podataka, a može potrajati. Na primjer, imat ćete priliku obnoviti bazu podataka vraćanjem unatrag iz log datoteke (koju smo, nažalost, "lupali" u metežu restauracije) ili na neki drugi način. Dakle, dopustite mi da vas podsjetim da bi negdje trebala postojati SQL baza podataka, bez obzira na podatke, ali s istom konfiguracijom. Ako je vaša konfiguracija tipična "nedirnuta" (što znači da je ovaj problem nastao tijekom skupljanja nove tipične konfiguracije) - možete stvoriti novu praznu bazu podataka i ispuniti tipičnu konfiguraciju koju ste imali prije. Ako konfiguracija koju ste pronašli nije tako svježa - razmislite o tome i donesite odluku, možda će te razlike s kopijom konfiguratora koje ćete biti prisiljeni ponoviti u svojoj bazi podataka oduzeti puno više vremena i resursa nego gubitak informacija iz sama baza podataka 1C. Neka vrsta mača s dvije oštrice) Dakle ...

1. Izrađujemo sigurnosnu kopiju neispravne baze podataka koristeći SQL.

2. Čistimo dbo.config tablicu naše baze podataka u kojoj se nalazi naš pokvareni conf. To se može učiniti iz SQL Profilera, na primjer, pokretanjem naredbe u njemu:

Izbriši iz.

gdje je Base2009 naziv neuspjele baze.

Napomena: negdje na netu sam pročitao neprovjerene informacije, koje ponekad pomažu u čišćenju dbo.ConfigSave tablice, koja navodno sadrži smotani config. U našoj bazi podataka pokazalo se da je prazna, pa nisam očistio praznu tablicu. Možda - pomoću ove tablice možete nekako prevariti i oživjeti bazu 1C, ali, ne znajući mehanizam rada 1C s ovom tablicom, neću reći ništa u akcijskom planu u vezi s tim.

3. Kopirajte tablicu iz baze podataka s cijelom konfiguracijom u našu uništenu bazu podataka. U mom slučaju obje baze su bile na istom poslužitelju, pa je naredba kopiranja u SQL-Profileru izgledala ovako.

umetni u .. odaberi * iz ..

gdje je base2009 naziv neuspjele baze, BaseCopy je naziv baze s kopijom konfiguratora

4. Pokrećemo 1C, i ako uspijemo, skačemo, poput mene od sreće što smo uspjeli oživjeti bazu podataka bez gubitka informacija.

5. (Kapetan očito) provjeravamo, otklanjamo pogreške i pratimo sustav za izradu sigurnosnih kopija baze podataka i vrlo odgovorno pristupamo procesu ažuriranja konfiguracije (ne radimo to preko mreže, već po mogućnosti na poslužitelju, izrađujući sigurnosnu kopiju ako moguće). Pogotovo ako je vaša verzija 1C postala 8.2. Koliko sam shvatio iz članaka po netu i prva dva dana rada s njim, da je osjetljiviji i hirovitiji, u odnosu na 8.1 s kojim nije bilo takvih problema.

5a. Ako je konfiguracija baze iz koje ćete kopirati conf tablicu još uvijek drugačija (bez ikakvih razlika u metapodacima, što sam već spomenuo), a negdje se nalazi vaša relativno svježa cf datoteka s neučitanim confom, puštamo je dalje stambena baza. U suprotnom, morat ćete ponoviti sve razlike koje su bile s kopijom konfiguratora. Zato još jednom dobro razmislite i analizirajte - što je važnije - vaš rad na promjeni konfiguracije (i koliko ćete vremena na to potrošiti) ili rad korisnika baze podataka do zadnjeg backupa. U mom slučaju radilo se o radu 2 programera po 3 sata naspram rada oko 100 korisnika za 1,5 dan, tako da je izbor bio očit.

Z.Y. Podsjeti me opet? da je ova funkcija vraćanja nedokumentirana 1C-sheep metoda vraćanja baze (u konkretnom slučaju kolapsa baze do kojeg je došlo u procesu spremanja confa) i sve što radite - radite na vlastitu odgovornost i rizik, ali konkretno u mom slučaju postoje drugi načini za oživljavanje baze s minimalnim gubitkom postojećih informacija (datoteka dnevnika je izgubljena, a posljednja sigurnosna kopija predstavljala je gubitak 1,5 dana rada za oko 100 korisnika), stoga, kako su recimo, mostovi su spaljeni)

Z.Y.S. Ovo je moj prvi post ovdje. bojte se na drugim 1C forumima, ali smatram da je ovaj resurs jedan od najkorisnijih u smislu objavljenih razvoja i publikacija, stoga nemojte strogo suditi za puno IF-ova u ovoj publikaciji). Bio bih jako sretan da sam stvarno nekome pomogao oko obnove uništene baze, jer od ovoga je gori samo nuklearni rat)

Z.Y.Y.S. Nakon 3 tjedna problem se ponovio) Ovaj put je nekoliko sekundi potrošeno na rješenje (ako ne uzmete u obzir vrijeme stvaranja sigurnosne kopije), a čak ni korisnici nisu morali biti izbačeni.

_____________________________________________________________________________________________________________

Danas je došao kolega. Ista nevolja. Samo baza je testna a ne radna, a sama baza mu je utoliko - ali bitan mu je konfigurator. Tjedan dana je brbljao po njemu, a da nijednom nije učitao datoteku u cf i nije prebacio promjene u radnu bazu podataka. Pa - zašto ne kopati dublje već sa stolom?! Ovaj put je još lakše. Otvaram SQL Management Studio. Formiram zahtjev ispod tablice na poljima s trenutnim datumom promjene i vremenom kada je kod njega baza krenula - rezultat daje 2 zapisa. Prvo - Field FileName = "commit" Pa - lupi ovaj zapis - i uspio sam! Konfigurator je zaživio i baza podataka ponovno radi. Što treba učiniti?!

Dakle, u otvorenom prozoru SQL Management Studio tražimo našu bazu podataka - otvorimo Tables, tražimo tablicu s conf na kraju liste dbo.config na stolu - desni gumb - Otvoreni stol. Dalje u desnom prozoru idemo dolje u samoj tablici prema dolje abecednim redom do polja gdje FileName = "commit". Ustajemo na ovom zapisu - desnom tipkom miša - Izbrisati. Općenito, brišemo unos s binarnom datotekom. Zatim pokušavamo ući u konf. Prvo se pojavljuje ista pogreška. Vjerojatno nije uspjelo? u redu. A onda, prije nego što je izdao 2. poruku o nemogućnosti spremanja kao prije, računalo se zamislilo. Nakon 30 sekundi - O ČUDU! Konfigurator je otvoren. Pokušavam spremiti konfigurator (nakon spremanja cf datoteke). Konfiguracija je spremljena. Tako su i vukovi siti, a ovce na sigurnom. Nisam siguran u potpunu operativnost baze podataka nakon takvog uznemiravanja - stoga vam savjetujem da restrukturirate i ponovno izračunate rezultate kasnije navečer (prethodno, naravno, nakon što ste napravili arhivu). Sretno i pozitivne emocije)

Pješčanik

1C, vraćanje konfiguracije infobaze pomoću MS SQL-a

Jednom sam naišao na problem: prilikom ažuriranja konfiguracije iz repozitorija došlo je do kvara i 1C se zatvorio.

Kako se kasnije pokazalo, pohrana konfiguracije je uništena, a kada je konfiguracija ažurirana, konfiguracija baze podataka također je izletjela iz pohrane. Slična se pogreška dogodila prije s dinamičkim ažuriranjem IB-a.

Jer Ovaj problem nastao više nego jednom odlučio podijeliti opciju liječenja.

Sljedeći put kada pokrenete konfigurator, pojavila se greška: “Pažnja!!! Došlo je do pogreške prilikom ažuriranja podataka nakon posljednjeg restrukturiranja. Ponovno pokušati ažuriranje?" ako je odgovor potvrdan, dobivamo poruku: “Otkrivena je operacija spremanja nepotpune konfiguracije. Za nastavak rada morate dovršiti operaciju ”tada se aplikacija zatvara.

Prilikom analize ovog problema, pronađeno je nekoliko rješenja problema, svako rješenje radi u različitim slučajevima.

Opcija 1 (ako imate SQL backup s kopijom s identičnom konfiguracijom):

Kopija IB-a je raspoređena i zahtijeva se sljedeća konstrukcija:
KORISTI GO DELETE FROM .. GO UMETNI U .. ​​ODABERI * FROM .. GO
Istodobno se ponovno popunjava tablica u kojoj je pohranjena konfiguracija IS-a. Preporučljivo je izvršiti IS testiranje i korekciju nakon ove operacije.

Opcija 2 (ako nema sigurnosne kopije):

Ova je opcija tretirana kao kap koja je prelila čašu. Jer konfiguracija je bila u razvoju i malo su zaboravili na backup, oslanjajući se na pohranu.
U bazi podataka, dva zapisa se brišu iz tablice "Config" prema vrijednosti u stupcu "FileName" - dbStruFinal i commit

Podnese se sljedeći zahtjev:
KORISTITE GO DELETE FROM. WHERE FileName = "dbStruFinal" GO DELETE FROM . WHERE FileName = "commit" GO
Začudo, baza oživljava.

Oznake: 1s enterprise 8.2, SQL, vraćanje konfiguracije

Ovaj članak nije podložan komentarima jer njegov autor još nije punopravni član zajednice. Autora ćete moći kontaktirati tek nakon što primi

Pješčanik

1C, vraćanje konfiguracije infobaze pomoću MS SQL-a

• Microsoft SQL Server
• Administracija baze podataka

Jednom sam naišao na problem: prilikom ažuriranja konfiguracije iz repozitorija došlo je do kvara i 1C se zatvorio.

Kako se kasnije pokazalo, pohrana konfiguracije je uništena, a kada je konfiguracija ažurirana, konfiguracija baze podataka također je izletjela iz pohrane. Slična se pogreška dogodila prije s dinamičkim ažuriranjem IB-a.

Jer Ovaj problem nastao više nego jednom odlučio podijeliti opciju liječenja.

Sljedeći put kada pokrenete konfigurator, pojavila se greška: “Pažnja!!! Došlo je do pogreške prilikom ažuriranja podataka nakon posljednjeg restrukturiranja. Ponovno pokušati ažuriranje?" ako je odgovor potvrdan, dobivamo poruku: “Otkrivena je operacija spremanja nepotpune konfiguracije. Za nastavak rada morate dovršiti operaciju ”tada se aplikacija zatvara.

Prilikom analize ovog problema, pronađeno je nekoliko rješenja problema, svako rješenje radi u različitim slučajevima.

Opcija 1 (ako imate SQL backup s kopijom s identičnom konfiguracijom):

Kopija IB-a je raspoređena i zahtijeva se sljedeća konstrukcija:
KORISTI GO DELETE FROM .. GO UMETNI U .. ​​ODABERI * FROM .. GO
Istodobno se ponovno popunjava tablica u kojoj je pohranjena konfiguracija IS-a. Preporučljivo je izvršiti IS testiranje i korekciju nakon ove operacije.

Opcija 2 (ako nema sigurnosne kopije):

Ova je opcija tretirana kao kap koja je prelila čašu. Jer konfiguracija je bila u razvoju i malo su zaboravili na backup, oslanjajući se na pohranu.
U bazi podataka, dva zapisa se brišu iz tablice "Config" prema vrijednosti u stupcu "FileName" - dbStruFinal i commit

Podnese se sljedeći zahtjev:
KORISTITE GO DELETE FROM. WHERE FileName = "dbStruFinal" GO DELETE FROM . WHERE FileName = "commit" GO
Začudo, baza oživljava.

Oznake: 1s enterprise 8.2, SQL, vraćanje konfiguracije

Ovaj članak nije podložan komentarima, budući da njegov autor još nije punačlan zajednice. Autora ćete moći kontaktirati tek nakon što primi