Пісочниця
Валера 18 вересня 2013 року о 15:241С відновлення конфігурації інформаційної бази з використанням MS SQL
- Microsoft SQL Server ,
- Адміністрація баз даних
Свого часу зіткнувся з проблемою: при оновленні конфігурації зі сховища стався збій і закрилася 1С.
Як з'ясувалося пізніше - відбулося руйнування сховища конфігурації та при оновленні конфігурації зі сховища злетіла і конфігурація БД. Подібна помилка виникала насамперед при динамічному оновленні ІБ.
Т.к. дана проблема виникала неодноразово вирішила поділитися варіантом лікування.
При наступному запуску конфігуратора виникла помилка: «Увага! При оновленні даних після останньої реструктуризації сталася помилка. Повторити оновлення? при ствердній відповіді отримуємо повідомлення: «Виявлено незавершену операцію збереження конфігурації. Для продовження роботи необхідно завершити операцію» після цього програма закривається.
При розборі цієї проблеми було знайдено кілька варіантів вирішення проблеми, кожне рішення працює у різних випадках.
Варіант 1 (за наявності бекапу SQL з копією з ідентичною конфігурацією):
Розгортається копія ІБ, і виконується запит наступної конструкції:
USE GO DELETE FROM .. GO INSERT INTO .. SELECT * FROM .. GO
При цьому переливається таблиця в якій зберігається конфігурація ІБ. Бажано після цієї операції виконати тестування та виправлення ІБ.
Варіант 2 (за відсутності бекапу):
До цього варіанта звернулися як до останньої соломинки. Т.к. Конфігурація була в стадії розробки і про бекап трохи забули сподіваючись на сховище.
У базі видаляються два записи з таблиці Config за значенням у стовпці FileName - dbStruFinal і commit
Виконується наступний запит:
USE GO DELETE FROM. WHERE FileName = "dbStruFinal" GO DELETE FROM . WHERE FileName = "commit" GO
Як не дивно, база оживає.
Теги: 1с підприємство 8.2, SQL, відновлення конфігурації
Ця стаття не підлягає коментуванню, оскільки її автор ще не є повноправним учасником спільноти. Ви зможете зв'язатися з автором лише після того, як він отримає
Передісторія.
Два дні тому здійснили перехід з 8.1 на 8.2 – змінювали конфу УПП 1.2... на 1.3.22.1. Відповідно купа відмінностей від типової конфігурації, які накочували - спричинило купу помилок. Два дні, не ночуючи, змінюємо конфігурацію як нон-стоп. Конфігуратор зберігається 15 разів на годину. Слід очікувати, що з збереженні, конфігурація може вилетіти, що саме і сталося. Такі проблеми в конфі 8.1 завжди вирішувалися виходом користувачів, які ще працювали в базі, але вже не могли повторно увійти і монопольним доступом. У нашій новій конфігурації 8.2 база сказала нам "Я втомився. Я йди"), загалом проблема описана в анонсі.
Що було з правильного і неправильного. І порада про те, що робити насамперед.
Насамперед ми в метушні починаємо шукати способи вирішення проблеми, що виникла в інтернеті. Google дає буквально 3 статті на даний момент за текстом помилки, що виникає. Перелічу їх.
Загалом у всіх трьох статтях відповідь на вирішення поточної проблеми одна - "Відновлюйте базу з бекапу".
Не варто говорити про важливість бекапів їх регулярності та інше. Вважаю, що в плані нас це було хорошим попередженням, хоча у нас і був бекап бази після її збереження в конфігурації 1.3, але за їх регулярністю і тим, що вони робляться (а вінчестер не чиститься та інше), за цим мало хто стежить. Відповідно вибачте за "капітана очевидність", але якщо у вас є свіжий бекап - насамперед і займіться відновленням бази з нього, не втрачайте дорогоцінний час, за простий якого керівництво вам не подякує. Однак можна спробувати оживити базу, що впала, що завдяки моїй настирливості було і зроблено. Зазначу, що іншим програмістом також були прийняті спроби якось оживити базу 1с-вськими способами, але вони були безуспішними. Не знаю всього, що він робив, але бачив спроби запуску 1С у командному режимі одразу із запуском Тестування та виправлення ІБ, які власне нічого не запускали.
Я звернув увагу на SQL. Невеликий досвід конфігурування та адміністрування баз і типовий набір sql-команд мені знайомий, але викладений нижче спосіб не потребує ніяких глибоких знань і навичок роботи з SQL. Я просто підключив логіку - якщо база "впала" в момент збереження конфігурації, робимо висновок, що в SQL могла порушитися структура однієї таблиці (хоча я не знав до того, що конфігурація в 8 версії лежить в одній сиквель таблиці) і ця таблиця в якій зберігається Зміна бази. а саме таблиця dbo.config. Це згодом я дізнався методом "самотика" і знову ж таки логіки, бо єдине що знайшов це місцеву розробку, мені не допомогло але досить корисну на майбутнє, а саме Дякую автору від обліку мого колеги, за допомогою якого я її скачав. Отже переходжу до найважливішого - спроби(!) відновлення бази бо гарантій ніяких я вам, на жаль, дати не можу і тому є низка передустановок, яких у вас може і не бути або як кажуть - це не ваш випадок.
Вимоги і саме відновлення бази.
(Увага. Подивіться обов'язково виноску знизу, якщо хочете спробувати оживити і саму конфігурацію. Сьогодні (18.04.2012) шляхом експериментів мені це вдалося, бо стало шкода тижнева праця, яка була зроблена над нею. Таким чином вийшло базу оживити, залишивши старий конфігуратор без жодних копій).
Вихідні дані - SQL база 1С 8.2, конфігурація УПП 1.3.22.1 (вважаю, описаний спосіб підійде для будь-якої ескюельної бази 8.2). SQL сервер 2005. Помилка описана в анонсі і помилка, що виникла в момент збереження конфігурації! Найважливіша та обов'язкова вимога! Копія SQL бази з ТАКОЙ Ж КОНФІГУРАЦІЄЮ (!) У нас налаштований авто-обмін з іншою базою і конфігурації їх збігаються. Крім цього, тому що нас троє програмістів 1С - у кожного є вивантажений і відносно новий файл конфи. По факту підійде будь-яка база, будь-яким з даними, головне щоб конфігурація в ній відповідала структурі метаданих бази. Відзначу той факт, що конфігурація навіть трохи відрізнялася від тієї, з якої база вилетіла. Найголовніше, на мій погляд, вимога, щоб відмінності в конфігурації не торкалися метаданих. Не варто забувати той факт, що якщо конфігурація відрізняється, то в результаті ви отримаєте робочу базу, але з конфігурацією з вашої копії.
Сам процес відновлення не займе у вас багато часу - буквально пару хвилин, але вкрай рекомендую попередньо зробити бекап навіть бази, що "впала", а він може зайняти час. Наприклад у вас буде можливість відновити базу відкатом з log-файлу (який у нас на жаль у метушні відновлення "грохнули") або ще якийсь спосіб. Отже, нагадаю що десь має бути SQL база будь-якими даними але з такою ж конфігурацією. Якщо у вас конфігурація є "недоторканою" типовою (що передбачає, що дана проблема виникла в процесі накату нової типової конфігурації) - можете створити нову порожню базу і залити туди типову конфу, яка у вас була до цього. У випадку, якщо конфігурація, яку ви знайшли, не така вже свіжа - подумайте і ухваліть рішення, можливо ті відмінності з копією конфігуратора, які ви будете змушені повторити у вашій базі, займуть набагато більше часу та ресурсів, ніж втрата інформації самої бази даних 1С . Своєрідна палиця з двома кінцями) Отже...
1. Робимо бекап бази, що обвалилася засобами SQL.
2. Очищаємо таблицю dbo.config нашої бази, в якій лежить наша порушена конфа. Це можна зробити з SQL-Profiler, наприклад запустивши в ньому команду:
Delete From.
де Base2009 ім'я обвалу бази.
Примітка: десь у мережі читав неперевірену інфу, що іноді допомагає очищення таблиці dbo.ConfigSave, в якій, нібито, лежить конфа, що накочується. У нашій базі вона виявилася порожньою, тому чистити порожню таблицю, зрозуміло не став. Можливо - можна як-небудь обдурити і оживити базу 1С, використовуючи цю таблицю але, не знаючи механізм роботи 1С з цією таблицею, нічого не говоритиму в плані дій, стосовно неї.
3. Копіюємо таблицю з бази з цілою конфігурацією, в нашу порушену базу. У моєму випадку обидві бази були на одному сервері, тому команда копіювання в SQL-Profiler виглядала так.
insert into .. select * from ..
де base2009 - ім'я бази, що обвалилася, BaseCopy ім'я бази з копією конфігуратора
4. Запускаємо 1С, і в разі успіху – стрибаємо, як я від радості, що вдалося оживити базу без жодних втрат інформації.
5. (Капітан очевидність) перевіряємо налагоджуємо і стежимо за системою створення бекапів бази та дуже відповідально підходимо до процесу оновлення конфігурації (робимо це не по мережі, а бажано на сервері, по можливості зробивши попередньо бекап). Особливо якщо версія вашої 1С стала 8.2. Наскільки я зрозумів зі статей у мережі і перших двох днів роботи з нею, що вона більш чутлива і примхлива, порівняно 8.1 з якою таких проблем не було.
5а. Якщо конфігурація бази з якою ви копіюватимете таблицю конфи - все-таки відрізняється, (не маючи при цьому відмінностей у метаданих, про що я вже говорив), і десь лежить ваш відносно свіжий cf-файл з вивантаженою конфою - накочуємо його на ожилу базу. А якщо ні, то Вам доведеться повторити всі ті відмінності, які були з копією конфігуратора. Так що ще раз добре подумайте та проаналізуйте – що важливіше – ваша робота зі зміни конфігурації (і скільки часу ви на це витратите) або робота користувачів бази до моменту останнього бекапу. У моєму випадку це була робота 2-х програмістів протягом 3-х годин проти роботи близько 100 користувачів протягом 1.5 днів, тому вибір був очевидний.
З.И. Ще раз нагадаю? що ця функція відновлення є недокументованим 1С-овцами способом відновлення бази (у разі обвалення бази, що сталося у процесі збереження конфи) і що ви робите - ви робите власний страх і ризик, але у моєму разі інших шляхів оживити базу з мінімальної втратою існуючої інформації не було (лог файл потерли і найсвіжіший бекап представляв втрату 1.5 дня роботи близько 100 користувачів), тому, як кажуть мости були спалені)
З.И.И. Це перша публікація тут т.к. трусь на інших 1С форумах, але знаходжу цей ресурс одним з найкорисніших у плані викладених розробок та публікацій, тому не судіть строго за багато (якщо в даній публікації). Буду дуже радий, якщо реально допоміг комусь із відновленням порушеної бази бо страшніше за це тільки ядерна війна)
З.И.Ы.Ы. Через 3 тижні проблема повторилася) Цього разу на рішення було витрачено якісь секунди (якщо не враховувати час створення бекапу) і навіть користувачів не довелося виганяти.
_____________________________________________________________________________________________________________
Сьогодні прибіг колега. Те саме лихо. Тільки база тестова а не робоча і сама база йому оскільки остільки - а ось конфігуратор йому важливий. Тиждень він краптел над ним жодного разу не вивантаживши в cf файл і не набравши зміни до робочої бази. Ну що ж - чому б не поколупаються вже з таблицею?! На цей раз все ще простіше. Відкриваю SQL Management Studio. Формую запит по таблиці на поля з поточною датою зміни та часом коли у нього вилетіла база – результат дає 2 записи. Перша - Поле FileName = "commit" Ну що ж - гримнути цей запис - і в мене все вийшло! Конфігуратор ожив і основа знову працює. Що ж потрібно зробити?
Отже, у відкритому вікні SQL Managment Studio шукаємо нашу базу - відкриваємо Таблиці, шукаємо в кінці списку таблицю з конфою dbo.configна таблиці - праву кнопку - Відкрити таблицю. Далі в правому вікні спускаємося в самій таблиці вниз по алфавіту на полі, де FileName = "commit". Стаємо на цей запис - праву кнопку миші - Видалити.Загалом видаляємо запис із двійковим файлом. Далі пробуємо зайти в конфу. Помилка та сама перша з'являється. Напевно не вийшло? Натискаємо Ок. І тут, як видати як раніше 2-е повідомлення про неможливість зберегти - комп'ютер задумався. Через секунд 30 - ПРО ДИВО! Конфігуратор відчинився. Спробуємо зберегти конфігуратор (попередньо зберігши cf файл). Конфігуратор зберігається. Таким чином і вовки ситі та вівці цілі. Не впевнений щодо повної працездатності бази після таких знущань - тож пораджу зробити реструтуризацію та перерахунок підсумків вже потім увечері (попередньо звичайно ж зробивши архів). Вдалого відновлення та позитивних емоцій)
Ми переїжджали на новий сервер. На ньому SQL та 1C. У порівнянні зі старими був набагато крутіший. І тест Гільова це теж підтвердив: проти 10-15 на старих серверах видавав 39. Тому ми одразу після покупки перенесли базу та розпочали роботу.
Але рано чи пізно щось пішло не так — користувачі почали скаржитися на повільну роботу. Зробили певні налаштування сервера та служб (які - тема окремого поста) і вирішили перезавантажити сервер, благо швидкість перезавантаження - 2 хвилини (на інших серверах до 10 доходило). Після цього при вході в 1С отримуємо таке повідомлення:
"Увага!!! При оновленні даних після останньої реструктуризації сталася помилка. Повторити оновлення? "Та ні"
Після натискання кнопки «Так» з'являється таке:
«Виявлено незавершену операцію збереження конфігурації. Для продовження роботи необхідно завершити операцію.
Перше, що вирішив зробити - CHECKDB на Managment Studio - після 2х годин очікування (база 500 ГБ) - все ОК.
На просторах мережі знайшов інформацію, що така ж помилка буває за динамічного оновлення.
Рішення, запропоновані в мережі відразу не допомогли, але разом з іншими події дали результат. Отже, що я робив:
Рішення:
- Те, чого не вистачало для рішень із мережі:
sp_configure 'allow updates', 1
reconfigure with override
go
2. Переводимо базу в режим відновлення
alter database set EMERGENCY, SINGLE_USER
3. Виконуємо тестування бази:
dbcc checkdb('db_name', REPAIR_ALLOW_DATA_LOSS)
4. Виводимо базу з режиму відновлення:
alter database set ONLINE, MULTI_USER
5. У принципі, якщо впевнені, що з самою базою все ок, то можна не робити 2-4 пункти. Далі виконуємо два запити у профайлері SQL:
delete from config where FileName = ‘commit’
delete from config where FileName = ‘dbStruFinal’Ці записи відповідають за динамічне оновлення — можна не боятися їх видаляти.
У робочих версіях баз запити:
select * from Config WHERE FileName = ‘commit’
select * from Config WHERE FileName = ‘dbStruFinal’
будуть порожні.
6. повертаємо налаштування:
sp_configure 'allow updates', 0
go
7. Після цього вдалося запустити конфігуратор та база запрацювала.
Також база може працювати після видалення першого прапора.
Проблема, якій присвячена стаття, виникає при аварійному завершенні роботи конфігуратора у той час, коли відбувається реструктуризація бази даних, тобто - одному з останніх етапів оновлення конфігурації. Рішення, описане у статті, відноситься до клієнт-серверної версії платформи "1С: Підприємство", яка використовує як СУБД "MS SQL Server".
Симптомами можуть бути такі попередження системи:
1)При спробі запуску бази як конфігуратора:
2)При спробі запуску бази в режимі підприємства:
3)При вході в конфігуратор система може запропонувати таке рішення:
На це питання ми можемо відповісти ствердно. І часто в такий спосіб проблема вирішується. Але не завжди.
На нашу згоду продовжити оновлення система може відповісти наступним повідомленням:
Або ж вимагати монопольного доступу, що не завжди зручно в системах з великою кількістю користувачів, а іноді просто неможливо.
І тут нам допоможе MS SQL Server. Для вирішення нашої проблеми досить послідовно виконати такі скрипти (зрозуміло в контексті проблемної БД).
1) Спочатку створимо копії таблиць Config та ConfigSave (згодом їх можна видалити).
SELECT *
INTO Config _ copy
FROM [ Config ]
SELECT *
INTO ConfigSave_copy
FROM
У цих таблицях якраз і зберігається інформація про конфігурації та хід оновлення. У першій таблиці зберігається інформацію про конфігурації БД, зокрема, і дані останнього оновлення. Друга таблиця містить дані нової, ще незбереженої конфігурації. Аналізуючи зміст цих таблиць, система отримує дані у тому, наскільки успішним (чи неуспішним) було останнє оновлення.
2) Видаляємо всі записи з таблиці ConfigSave (зберігає конфігурацію, що накочується)
DELETE FROM
3) Видаляємо три записи з таблиці Config (саме вони зберігають інформацію про незакінчений процес оновлення конфігурації)
DELETE FROM
WHERE FileName IN ("commit" , "dbStruFinal" , "dynamicCommit" )
У таблиці Config повинні з'явитися записи про останнє оновлення, що легко перевірити звичайним «селектом».
