Після останньої реструктуризації сталася критична помилка. Аварійне завершення оновлення конфігурації бази даних

Пісочниця

Валера 18 вересня 2013 року о 15:24

1С відновлення конфігурації інформаційної бази з використанням 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, відновлення конфігурації

Нещодавно мені довелося відновлювати базу «1С підприємство 8» після падіння, яке відбулося під час оновлення конфігурації. Причому це було двічі і методи, застосовані при відновленні, теж були різними (скоро дізнаєтеся чому). У цій статті я хочу розповісти про ті способи, якими я скористався.

Всі способи, що розглядаються в статті, відносяться до серверного варіанту роботу «1С підприємство 8», що використовується СУБД - MS SQL 2005.

Випадок №1.

При оновленні конфігурації було видано помилку «Конфлікт блокувань», конфігуратор було закрито. При повторній спробі входу в конфігуратор виникла помилка: Увага!!! При оновленні даних після останньої реструктуризації сталася помилка. Повторити оновлення? "Та ні"

При позитивній відповіді видавалося таке повідомлення «Виявлено незавершену операцію збереження конфігурації. Для продовження роботи необхідно завершити операцію.

Пошуки на просторах інтернету видали такий спосіб. В таблиці Configнашої бази даних необхідно видалити рядки де поле FileName = commitабо FileName = dbStruFinal або FileName=DynamicallyUpdated (для 8.3) або FileName=dynamicCommit (8.3), а також очистити таблицю ConfigSave. Поясню за що відповідають дані таблиці: Config - у цій таблиці зберігається конфігурація бази даних, ConfigSave - у цій таблиці зберігається робоча конфігурація, тобто. до натискання кнопки F7у конфігураторі.

Відкриваємо SQL Serger Managment Studio та відкриваємо вікно запитів за кнопкою « New Query» Відкриває вікно запитів.

У вікні запитів пишемо запити та виконуємо їх:

  1. delete from [Ім'яНашоїБази].. where FileName = ‘commit’
  2. delete from [Ім'яНашоїБази].. where FileName = ‘dbStruFinal’
  3. delete from [Ім'яНашоїБази].. where FileName = ‘DynamicallyUpdated’ (для версії 8.3)
  4. delete from [Ім'яНашоїБази].. where FileName = ‘dynamicCommit’ (для версії 8.3)
  5. delete from [Ім'яНашоїБази]

Після виконання цих запитів конфігуратор запустився без проблем.

Випадок №2

Причина помилки входу в конфігуратор така ж, як і в першому випадку: конфлікт блокувань при оновленні конфігурації.

Видалення рядків у таблиці Configта очищення таблиці ConfigSaveдопомогло частково: конфігуратор відкривався, але на підприємстві не працювали керовані форми.

В даному випадку спадало на думку 2 шляхи розвитку:

  1. Відновлення із архіву. У цьому випадку було одне велике «АЛЕ»: так вийшло, що архів створився після оновлення, тобто. архів був помилково.
  2. Була ідея використовувати конфігурацію розподіленої бази, яка не оновилася, тому що файл обміну був з помилкою.

Для вирішення проблеми було обрано другий варіант. Далі покроково розповім, що робив.

  1. Відкриваємо SQL Serger Managment Studio та створюємо довільну базу, наприклад Perenos.У цій базі створюємо таблицю Config.Хто не знає SQL для перенесення даних з однієї таблиці в іншу, то у MS SQL є чудовий сервіс. SQL Server import and Export Wizard“. За допомогою даного сервісу можна легко переносити дані з однієї бази в іншу. Щоб запустити цей сервіс, необхідно натиснути клавіші « ctrl+r» та у вікні діалогу написати команду « dtswizard «.
  2. Переносимо за допомогою сервісу dtswizardдані таблиці Configнашої бази до таблиці Configбази Perenos.
  3. Очищуємо таблицю Configу нашій базі за допомогою запиту delete from [Ім'яНашоїБази]
  4. На сервері, де знаходиться розподілена база, запускаємо сервіс dtswizardта переносимо дані з таблиці Configу таку ж таблицю лише нашій базі.

Ось за допомогою таких дій вдалося швидко і з мінімальним простоєм відновити працездатність бази.

Пісочниця

Залізна людина 18 вересня 2013 року о 15:24

1С відновлення конфігурації інформаційної бази з використанням MS SQL

Свого часу зіткнувся з проблемою: при оновленні конфігурації зі сховища стався збій і закрилася 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

Як не дивно, база оживає.

Ми переїжджали на новий сервер. На ньому SQL та 1C. У порівнянні зі старими був набагато крутішим. І тест Гільова це теж підтвердив: проти 10-15 на старих серверах видавав 39. Тому ми одразу після покупки перенесли базу та розпочали роботу.

Але якоїсь миті щось пішло не так — користувачі почали скаржитися на повільну роботу. Зробили певні налаштування сервера та служб (які - тема окремого поста) і вирішили перезавантажити сервер, благо швидкість перезавантаження - 2 хвилини (на інших серверах до 10 доходило). Після цього при вході в 1С отримуємо таке повідомлення:

"Увага!!! При оновленні даних після останньої реструктуризації сталася помилка. Повторити оновлення? "Та ні"

Після натискання кнопки «Так» з'являється таке:

«Виявлено незавершену операцію збереження конфігурації. Для продовження роботи необхідно завершити операцію.

Перше, що вирішив зробити - CHECKDB на Managment Studio - після 2х годин очікування (база 500 ГБ) - все ОК.

На просторах мережі знайшов інформацію, що така ж помилка буває за динамічного оновлення.

Рішення, запропоновані в мережі відразу не допомогли, але разом з іншими події дали результат. Отже, що я робив:

Рішення:

  1. Те, чого не вистачало для рішень із мережі:

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 повинні з'явитися записи про останнє оновлення, що легко перевірити звичайним «селектом».