Відновлення працездатності SQL бази - 1С підприємство 8 - після падіння під час оновлення,

Вітаю Вас, дорогі читачі.

Нещодавно мені довелося відновлювати базу «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 [Ім'яНашоїБази].[dbo].[Config] where FileName = ‘commit’
  2. delete from [Ім'яНашоїБази].[dbo].[Config] where FileName = ‘dbStruFinal’
  3. delete from [Ім'яНашоїБази].[dbo].[Config] where FileName = ‘DynamicallyUpdated’ (для версії 8.3)
  4. delete from [Ім'яНашоїБази].[dbo].[Config] where FileName = ‘dynamicCommit’ (для версії 8.3)
  5. delete from [Ім'яНашоїБази].[dbo].[ConfigSave]

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

Випадок №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 [Ім'яНашоїБази].[dbo].[Config]
  4. На сервері, де знаходиться розподілена база, запускаємо сервісdtswizard і переносимо дані з таблиціConfig в таку ж таблицю тільки в нашій базі.

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