Pozdrav dragi čitaoci.

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

Sve metode o kojima se govori u članku odnose se na serversku verziju rada "1C Enterprise 8", koju koristi DBMS - MS SQL 2005.

Slučaj broj 1.

Prilikom ažuriranja konfiguracije generirana je greška "Konflikt zaključavanja", konfigurator je zatvoren. Kada sam ponovo pokušao da uđem u konfigurator, pojavila se greška: Pažnja!!! Došlo je do greške prilikom ažuriranja podataka nakon posljednjeg restrukturiranja. Pokušati ponovo ažurirati?" "Ne baš"

Ako je odgovor bio potvrdan, prikazala se sljedeća poruka "Otkrivena je nepotpuna operacija spremanja konfiguracije. Morate završiti operaciju da nastavite."

Pretrage na Internetu dale su sljedeću metodu. Table config naša baza podataka treba da obriše redove u kojima je polje Ime datoteke = urezivanje ili FileName = dbStruFinal ili FileName=Dynamically Updated (za 8.3) ili FileName=dynamicCommit (8.3) i očistite sto ConfigSave. Da objasnim za šta su odgovorni podaci tabele: Config - ova tabela pohranjuje konfiguraciju baze podataka, ConfigSave - ova tabela pohranjuje radnu konfiguraciju, tj. prije pritiska na dugme F7 u konfiguratoru.

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

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. izbrisati iz [OurBaseName].. gdje je FileName = 'dynamicCommit' (za verziju 8.3)
5. izbriši iz [OurBaseName]..

Nakon izvršenja ovih zahtjeva, konfigurator je pokrenut bez ikakvih problema.

Slučaj #2

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

Brisanje redova u tabeli config i raščišćavanje stola ConfigSave djelomično je pomoglo: otvoren je konfigurator, ali preduzeće nije radilo upravljane forme.

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

1. Oporavak iz arhive. U ovoj verziji postojalo je jedno veliko „ALI“: dogodilo se da je arhiva stvorena nakon ažuriranja, tj. arhiva je bila pogrešna.
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 šta sam uradio.

1. Otvorite SQL Serger Management Studio i kreirajte proizvoljnu bazu podataka, na primjer Perenos. Kreirajte tabelu u ovoj bazi podataka config. Ko ne zna sql da prenosi podatke iz jedne tabele u drugu, onda MS SQL ima divnu uslugu " Čarobnjak za uvoz i izvoz SQL Servera". Koristeći ovu uslugu, lako možete prenijeti podatke iz jedne baze podataka u drugu. Da pokrenete ovu uslugu, pritisnite " ctrl+r" i u dijaloškom okviru upišite naredbu " dtswizard «.
   
2. Prijenos uz uslugu dtswizard tabelarni podaci config našu bazu podataka u tabelu config baze Perenos.
3. Čišćenje stola config u našoj bazi podataka sa upitom izbriši iz [OurBaseName]..
4. Na serveru na kojem se nalazi distribuirana baza podataka pokrećemo servis dtswizard i prenijeti podatke iz tabele config u istu tabelu samo u našoj bazi podataka.

Uz pomoć takvih radnji pokazalo se da se baza podataka brzo i s minimalnim zastojima vraća u radni kapacitet.

Praistorija.

Prije dva dana smo izvršili prijelaz sa 8.1 na 8.2 - promijenili smo konfiguraciju SCP 1.2 ... u 1.3.22.1. U skladu s tim, mnogo razlika u odnosu na tipičnu konfiguraciju koja je nastala - dovela je do mnogo grešaka. Dva dana, bez prenoćišta, non-stop mijenjamo konfiguraciju. Konfigurator se pohranjuje 15 puta na sat. Bilo je za očekivati ​​da bi prilikom spremanja konfiguracija mogla pasti, što se i dogodilo. Takvi problemi, u conf 8.1, uvijek su se rješavali odjavljivanjem korisnika koji su još uvijek radili u bazi podataka, ali se više nisu mogli ponovo prijaviti sa ekskluzivnim pristupom. U našoj novoj 8.2 konfiguraciji, baza nam je rekla "Umoran sam. Odlazim"), općenito, problem je opisan u najavi.

Šta je uzeto od ispravnog i pogrešnog. I savjet šta prvo učiniti.

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

Generalno, u sva tri članka, odgovor na rješavanje trenutnog problema je isti - "Vrati bazu podataka iz sigurnosne kopije."

Ne pričajte o važnosti rezervnih kopija o njihovoj redovnosti i tako dalje. Mislim da je za nas ovo bilo dobro upozorenje, iako smo imali rezervnu kopiju baze podataka nakon što smo je sačuvali u konfiguraciji 1.3, ali malo ko prati njihovu regularnost i činjenicu da su gotovi (a hard disk nije očišćen, itd.). U skladu s tim, oprostite "kapetanu očigledno", ali ako imate svježu sigurnosnu kopiju - prvo što trebate učiniti je obnoviti bazu podataka iz nje, ne gubite dragocjeno vrijeme, na čemu vam uprava neće zahvaliti za vrijeme mirovanja. Međutim, možete pokušati da oživite "palu" bazu, što je, zahvaljujući mojoj upornosti, i preduzeto. Napominjem da je i drugi programer pokušao nekako oživjeti bazu na 1c načine, ali su bili neuspješni. Ne znam sve što je radio, ali vidio sam pokušaje pokretanja 1C u komandnom modu odmah s pokretanjem Testiranja i popravljanja sigurnosti informacija, koji zapravo ništa nije pokrenuo.

Usredsredio sam svoju pažnju na SQL. Poznajem malo iskustva u konfigurisanju i administriranju baza podataka i tipičnog skupa sql komandi, ali dolje navedeni metod ne zahtijeva nikakvo duboko znanje i vještine u radu sa SQL-om. Upravo sam povezao logiku - ako je baza podataka "pala" u trenutku pohranjivanja 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 tablici nastavka ) i ovu tablicu u kojoj je pohranjena osnovna konfiguracija. naime tabela dbo.config. Kasnije sam to naučio metodom "samoguranja" i, opet, logikom, jer jedino što sam pronašao je lokalni razvoj koji mi nije pomogao, ali je bio od velike koristi za budućnost, odnosno hvala autoru od kolege račun sa kojeg sam ga preuzeo. Dakle, pređimo na ono najvažnije - pokušaje (!) da vratite bazu podataka, jer, nažalost, ne mogu vam dati nikakve garancije, a postoji niz unaprijed postavljenih postavki koje možda nemate ili, kako kažu, ovo nije tvoj slucaj...

Zahtjevi i restauracija same baze podataka.

(Pažnja. Obavezno pogledajte fusnotu ispod ako želite da pokušate da oživite samu konfiguraciju. Danas (18.04.2012.) to sam uspeo da uradim kroz eksperimente jer mi je bilo žao nedeljnog rada koji je rađen na njoj Tako se pokazalo da oživljava bazu 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 najavi i greška koja se dogodila u trenutku pohranjivanja konfiguracije! Najvažniji i obavezan uslov!!! Kopija SQL baze podataka sa ISTOM KONFIGURACIJOM(!) Postavili smo automatsku razmjenu sa drugom bazom podataka i njihove konfiguracije su iste. Osim toga, pošto smo mi tri 1C programera, svaki ima neučitanu i relativno svježu conf datoteku. U stvari, bilo koja baza podataka će raditi, bez obzira s kojim podacima, glavna stvar je da konfiguracija u njoj odgovara strukturi metapodataka baze podataka. Napominjem činjenicu da je konfiguracija bila čak malo drugačija od one s koje je baza poletjela. Najosnovniji, po mom mišljenju, zahtjev je da razlike u konfiguraciji ne utiču na metapodatke. Ne zaboravite činjenicu da ako je konfiguracija drugačija, onda ćete na kraju dobiti radnu bazu ali sa konfiguracijom iz vaše kopije.

Sam proces oporavka neće vam oduzeti mnogo vremena – samo nekoliko minuta, ali toplo preporučujem da prvo napravite sigurnosnu kopiju čak i „pale“ baze podataka, a to može potrajati. Na primjer, imat ćete priliku da vratite bazu podataka vraćanjem iz log datoteke (koju smo, nažalost, "lupali" u metežu restauracije) ili na neki drugi način. Dakle, da vas podsjetim da negdje treba postojati SQL baza podataka, bez obzira na podatke, ali sa istom konfiguracijom. Ako je vaša konfiguracija tipična "netaknuta" (što znači da je ovaj problem nastao u procesu pokretanja nove tipične konfiguracije) - možete kreirati novu praznu bazu podataka i popuniti tipičnu konfiguraciju koju ste ranije imali. Ako konfiguracija koju ste pronašli nije tako svježa - razmislite o tome i donesite odluku, možda će vam one razlike s kopijom konfiguratora koje ćete biti primorani ponoviti u svojoj bazi podataka oduzeti mnogo više vremena i resursa nego gubitak informacija iz sama 1C baza podataka. Neka vrsta mača sa dve oštrice) Dakle...

1. Pravimo sigurnosnu kopiju neuspjele baze podataka koristeći SQL.

2. Očistimo tabelu dbo.config 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 ime neuspjele baze.

Napomena: negdje na netu sam pročitao neprovjerene informacije, koje ponekad pomažu u čišćenju tabele dbo.ConfigSave, koja navodno sadrži valjanu konfiguraciju. U našoj bazi podataka ispostavilo se da je prazna, pa nisam obrisao praznu tabelu. Možda - možete nekako prevariti i oživjeti bazu 1C koristeći ovu tablicu, ali, ne poznavajući mehanizam rada 1C s ovom tablicom, neću ništa reći u akcionom planu u vezi s njom.

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

umetni u .. odaberite * iz ..

gdje je base2009 ime neuspjele baze, BaseCopy je ime baze sa kopijom konfiguratora

4. Pokrećemo 1C, i ako uspemo, skačemo, kao i ja od sreće što smo uspeli da oživimo bazu podataka bez gubitka informacija.

5. (Kapetan očigledno) provjeravamo, otklanjamo greške i pratimo sistem za kreiranje rezervnih kopija baze podataka i vrlo odgovorno pristupamo procesu ažuriranja konfiguracije (ovo ne radimo preko mreže, već po mogućnosti na serveru, praveći sigurnosnu kopiju ako moguće). Pogotovo ako je vaša 1C verzija postala 8.2. Koliko sam shvatio iz članaka na netu i prva dva dana rada sa njim, osjetljiviji je i hirovitiji u odnosu na 8.1 sa kojim nije bilo takvih problema.

5a. Ako je konfiguracija baze sa koje ćete kopirati conf tabelu i dalje drugačija (bez ikakvih razlika u metapodacima, što sam već spomenuo), a vaš relativno svjež cf fajl sa neučitanim confom je negdje, kotrljamo ga na live baza. U suprotnom ćete morati ponoviti sve razlike koje su bile s kopijom konfiguratora. Zato još jednom dobro razmislite i analizirajte – što je još važnije – svoj rad na promjeni konfiguracije (i koliko ćete vremena potrošiti na to) ili rad korisnika baze podataka do zadnjeg backup-a. U mom slučaju to je bio rad 2 programera 3 sata naspram rada oko 100 korisnika 1,5 dana, tako da je izbor bio očigledan.

Z.Y. Podsjeti me ponovo? da je ova funkcija vraćanja nedokumentirana 1C-ovca metoda vraćanja baze (u konkretnom slučaju kolapsa baze do kojeg je došlo u procesu spremanja conf) i sve što radite - radite na vlastitu odgovornost i rizik, ali konkretno u mom slučaju postoje i drugi načini da se baza oživi sa minimalnim gubitkom postojećih informacija (log fajl je izgubljen a poslednja rezervna kopija predstavlja gubitak od 1,5 dana rada za oko 100 korisnika), dakle, kako kažu 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 razvoja i objavljenih publikacija, tako da nemojte strogo suditi o mnogim IF-ovima u ovoj publikaciji). Bio bih jako sretan da sam stvarno pomogao nekome oko obnove uništene baze, jer je samo nuklearni rat gori od ovoga)

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

_____________________________________________________________________________________________________________

Danas je svratio kolega. Ista nevolja. Samo baza je probna a ne ispravna, a sama baza je za njega utoliko - ali mu je bitan konfigurator. Nedelju dana, on ga je skrembario, a da ni jednom nije učitao fajl u cf i bez ubacivanja promena 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 tabele na poljima sa trenutnim datumom promjene i vremenom kada je baza poletjela - rezultat daje 2 zapisa. Prvo - Field FileName = "commit" Pa - hajde ovaj zapis - i uradio sam to! Konfigurator je oživio i baza podataka ponovo radi. Šta treba uraditi?!

Dakle, u otvorenom prozoru SQL Management Studio-a, tražimo našu bazu podataka - otvaramo Tabele, tražimo tabelu sa conf na kraju liste dbo.config na stolu - desno dugme - Otvoreni sto. Dalje u desnom prozoru idemo dole u samoj tabeli po abecednom redu do polja gde je FileName = "urezivanje". Ustajemo na ovom zapisu - desno dugme miša - Izbriši. Općenito, brišemo unos sa binarnom datotekom. Zatim pokušavamo ući u conf. Prvo se pojavljuje ista greška. Vjerovatno nije uspjelo? uredu. A onda, prije nego što je dao drugu poruku o nemogućnosti štednje kao prije, kompjuter je pomislio. Nakon 30 sekundi - O ČUDU! Konfigurator je otvoren. Pokušavam da sačuvam konfigurator (nakon čuvanja cf fajla). Konfiguracija je sačuvana. Dakle, vukovi su siti, a ovce sigurne. Nisam siguran u potpunu operativnost baze podataka nakon ovakvog uznemiravanja - pa vam savjetujem da kasnije uveče restrukturirate i preračunate rezultate (prethodno, naravno, napravivši arhivu). Sretno i pozitivne emocije)

Sandbox

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

Jednom sam naišao na problem: prilikom ažuriranja konfiguracije iz spremišta, došlo je do greške i 1C se zatvorio.

Kako se kasnije ispostavilo, skladište konfiguracije je uništeno, a kada je konfiguracija ažurirana, konfiguracija baze podataka je također izletjela iz skladišta. Slična greška se dogodila ranije s dinamičkim ažuriranjem IB-a.

Jer Ovaj problem se pojavio više nego jednom odlučilo se podijeliti opciju liječenja.

Sljedeći put kada pokrenete konfigurator, pojavila se greška: “Pažnja!!! Došlo je do greške prilikom ažuriranja podataka nakon posljednjeg restrukturiranja. Pokušati ponovo ažurirati?" ako je odgovor da, dobijamo poruku: “Otkrivena je nepotpuna operacija spremanja konfiguracije. Da biste nastavili s radom, morate dovršiti operaciju ”tada se aplikacija zatvara.

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

Opcija 1 (ako imate SQL sigurnosnu kopiju s kopijom identične konfiguracije):

Kopija IB-a se postavlja i traži se sljedeća konstrukcija:
KORISTI GO DELETE FROM .. GO INSERT IN .. SELECT * FROM .. GO
Istovremeno se ponovo popunjava tabela u kojoj je pohranjena IS konfiguracija. Preporučljivo je izvršiti testiranje i korekciju IS nakon ove operacije.

Opcija 2 (ako nema rezervne kopije):

Ova opcija je tretirana kao posljednja kap. Jer konfiguracija je bila u razvoju i malo su zaboravili na backup, oslanjajući se na skladište.
U bazi podataka, dva zapisa se brišu iz tabele "Config" po vrijednosti u koloni "FileName" - dbStruFinal i urezivanje

Upućuje se sljedeći zahtjev:
KORISTI GO DELETE FROM . WHERE FileName = "dbStruFinal" GO DELETE FROM . WHERE FileName = "urezivanje" GO
Začudo, baza oživljava.

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

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

Sandbox

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

• Microsoft SQL Server
• Administracija baze podataka

Jednom sam naišao na problem: prilikom ažuriranja konfiguracije iz spremišta, došlo je do greške i 1C se zatvorio.

Kako se kasnije ispostavilo, skladište konfiguracije je uništeno, a kada je konfiguracija ažurirana, konfiguracija baze podataka je također izletjela iz skladišta. Slična greška se dogodila ranije s dinamičkim ažuriranjem IB-a.

Jer Ovaj problem se pojavio više nego jednom odlučilo se podijeliti opciju liječenja.

Sljedeći put kada pokrenete konfigurator, pojavila se greška: “Pažnja!!! Došlo je do greške prilikom ažuriranja podataka nakon posljednjeg restrukturiranja. Pokušati ponovo ažurirati?" ako je odgovor da, dobijamo poruku: “Otkrivena je nepotpuna operacija spremanja konfiguracije. Da biste nastavili s radom, morate dovršiti operaciju ”tada se aplikacija zatvara.

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

Opcija 1 (ako imate SQL sigurnosnu kopiju s kopijom identične konfiguracije):

Kopija IB-a se postavlja i traži se sljedeća konstrukcija:
KORISTI GO DELETE FROM .. GO INSERT IN .. SELECT * FROM .. GO
Istovremeno se ponovo popunjava tabela u kojoj je pohranjena IS konfiguracija. Preporučljivo je izvršiti testiranje i korekciju IS nakon ove operacije.

Opcija 2 (ako nema rezervne kopije):

Ova opcija je tretirana kao posljednja kap. Jer konfiguracija je bila u razvoju i malo su zaboravili na backup, oslanjajući se na skladište.
U bazi podataka, dva zapisa se brišu iz tabele "Config" po vrijednosti u koloni "FileName" - dbStruFinal i urezivanje

Upućuje se sljedeći zahtjev:
KORISTI GO DELETE FROM . WHERE FileName = "dbStruFinal" GO DELETE FROM . WHERE FileName = "urezivanje" GO
Začudo, baza oživljava.

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

Ovaj članak ne podliježe komentarima, jer njegov autor još nije punčlan zajednice. Autora ćete moći kontaktirati tek nakon što primi