Възстановяване на SQL база данни - 1C Enterprise 8 - след срив по време на актуализация,
Поздрави, скъпи читатели.
Съвсем наскоро трябваше да възстановя базата данни 1C Enterprise 8 след срив, възникнал по време на актуализация на конфигурацията. Освен това това се случи два пъти и методите, използвани при реставрацията също бяха различни (скоро ще разберете защо). В тази статия искам да говоря за методите, които използвах.
Всички методи, разгледани в статията, се отнасят до сървърната версия на работата "1C Enterprise 8", използвана от СУБД - MS SQL 2005.
Случай #1.
При актуализиране на конфигурацията се генерира грешка "Конфликт на заключване", конфигураторът беше затворен. При повторен опит да вляза в конфигуратора се появи грешка: Внимание. Възникна грешка при актуализиране на данните след последното преструктуриране. Опитайте отново актуализацията?" "Не точно"
Ако отговорът е да, се показва следното съобщение: „Открита е операция за запазване на непълна конфигурация. Трябва да завършите операцията, за да продължите."
Търсенето в интернет даде следния метод. В таблицатаConfig на нашата база данни трябва да изтриете редовете, където полето FileName = commit или FileName = dbStruFinal или FileName=DynamicallyUpdated (за 8.3) или FileName=dynamicCommit (8.3), и да изчистите таблицатаConfigSave. Нека обясня за какво отговарят данните от таблицата: Config - тази таблица съхранява конфигурацията на базата данни, ConfigSave - тази таблица съхранява работната конфигурация, т.е. преди да натиснете бутонаF7 в конфигуратора.
Отворете SQL Serger Management Studio и отворете прозореца на заявката, като щракнете върху бутона "Нова заявка ", за да отворите прозореца на заявката.
В прозореца за заявка напишетезаявки и ги изпълнете:
- изтриване от [OurBaseName].[dbo].[Config] където FileName = 'commit'
- изтриване от [OurBaseName].[dbo].[Config] където FileName = 'dbStruFinal'
- изтриване от [OurBaseName].[dbo].[Config] където FileName = 'DynamicallyUpdated' (за версия 8.3)
- изтриване от [OurBaseName].[dbo].[Config] където FileName = 'dynamicCommit' (за версия 8.3)
- изтриване от [OurBaseName].[dbo].[ConfigSave]
След изпълнението на тези заявки конфигураторът стартира без проблеми.
Случай #2
Причината за грешката при влизане в конфигуратора е същата като в първия случай: конфликт на заключване при актуализиране на конфигурацията.
Изтриването на редове в таблицатаConfig и изчистването на таблицатаConfigSave частично помогна: конфигураторът се отвори, ноуправляваните формуляри не работеха в предприятието.
В този случай ми дойдоха на ум 2 начина на развитие:
- Възстановяване от архива. В тази версия имаше едно голямо „НО“: случи се така, че архивът беше създаден след актуализацията, т.е. архивът беше грешен.
- Имаше идея да се използва конфигурацията на разпределената база данни, която не беше актуализирана, тъй като файлът за обмен беше с грешка.
За решаване на проблема беше избран вторият вариант. След това ще ви разкажа стъпка по стъпка какво направих.
- Отворете SQL Serger Management Studio и създайте произволна база данни, напримерPerenos. В тази база данни създайте таблицаConfig. Който не знае sql за прехвърляне на данни от една таблица в друга, тогава MS SQL има чудесна услуга "SQL Server import and Export Wizard ". Използвайки тази услуга, можете лесно да прехвърляте данни от една база данни в друга. За да стартирате тази услуга, трябва да натиснете клавишите "ctrl+r " и в диалоговия прозорецнапишете командата "dtswizard ".
- Използвайки услугата dtswizard, прехвърляме данните от таблицатаConfig на нашата база данни към таблицатаConfig на базатаPerenos.
- Изчистваме таблицатаConfig в нашата база данни, като използваме заявката за изтриване от [OurBaseName].[dbo].[Config]
- На сървъра, където се намира разпределената база данни, стартираме услугатаdtswizard и прехвърляме данните от таблицатаConfig в същата таблица само в нашата база данни.
С помощта на такива действия се оказа бързо и с минимално време на престой да се възстанови работоспособността на базата данни.