все что связано с моей работой
Главная » Технические » Снова СЭД и снова база.

Снова СЭД и снова база.

На днях снова приключилась беда, но на этот раз с СЭД-ом АП. что само по себе очень и очень странно, ведь УФК хорошо “следит” за своей базой. Но как говорится и на старуху бывает… Хотя правды ради стоит сказать, что проблема была вызвана не самим СЭД-ом, а скорее это была проблема MS SQL (для справки версия 2000). Но обо всем по порядку.

Итак СЭД-АП перестал сохранять документы (вернее вложение в “Произвольный» документ”) ругаясь, что мол SQL не может выделить больше места для базы. Как обычно полез проверять – так и есть файл базы (sed_ap.mdf) имеет размер 1 954Мб, размер лога (sed_ap_log.ldf) был 1мб.

У меня настроено еженочная архивация, и потом усечение (SHRINKDATABASE), поэтому лог-файл такой  маленький.

Делаю стандартную чистку (RBASE, TRANSPACKETSARC и тд) потом усечение, и … ничего! Размер файла базы так и остался 1,9г. Ладно, тогда тяжелая артиллерия — удаляю из KBKDRI все записи со статусом 4 (удаленные), к слову сказать их было не так много. Затем снова усечение и опять ничего.
И самое интересное, что реальный объём данных в базе примерно 1гиг, чуть больше. В ОТР на этот раз тоже не смогли помочь, MSSQL они официально не поддерживают, но есть официальная инструкция по переводу базы на него. Вот такая поддержка…

В общем чего только не перепробовал за этот день, сколько перечитал, но база ни на байт не уменьшилась. И самое не понятное, что при объеме данных в 1.1Г – размер базы 1.9Г и никак не уменьшается. То есть я удаляю «старые» записи – объем уменьшается, а размер нет. И можно было бы предположить дефрагментацию баз или что-то подобное, но при добавлении нового документа SQL не пытается выделить место из «мусора», путается увеличить файл базы. Такое ощущение, что он, SQL, не считает почти гиг мусора – мусором.

Но собственно, эта заметка не появилась бы, если б решение не было найдено.

Уж как я только не извращался и не подпрыгивал с бубном. В меню СЭД-а, нашел пункт  «Сервис – Служебное – Резервное копирование базы данных». Так как у меня база на SQL-сервере, и резервное копирование делаю средствами сервера, а этот пункт даже не замечал. Вариантов, возникло сразу несколько: архивация и потом сразу восстановление, SQL к примеру при таких действиях чистит лог и немного сжимает базу. Если не поможет, – то второй вариант: архивация – полная очистка базы (заново создать, если потребуется) и потом восстановление.

Плюсы этих вариантов: во-первых, архивирование средствами клиента – уберет весь лишний мусор, которые SQL ошибочно считает данными. Во-вторых, вернее следствие первого: если не помогут эти варианты – значит сервер не ошибся и мусора в базе нет, но это очень плохой расклад.

Выполнил копирование, оно отработало на удивление быстро, порядка получаса наверно. Удивлению не было предела. Те кто переносил базу на SQL или по другой причине делал экспорт из диктмана знают, сколько по времени этот процесс занимает – больше  8 рабочих часов или ночных. А при простое системы, по которой «приходят областные деньги», которые мы в свою очередь должны «отдать» в течение 3х дней… Задержка даже на 4-5 часов хватает чтоб пользователи начали по очереди интересоваться «как обстоят дела и когда все заработает, а то ж там областные могут быть». Поэтому это решение отметалось как не приемлемое по времени, но когда уже испробовано все, а ситуация не изменилась – как говориться: «на без рыбье и рак — рыба».

На радостях, такая скорость копирования базы, если восстановление займет даже в 4 раза больше времени, порядка 2х часов, это более чем приемлемое решение. Но пункта «восстановить» нет. Начал искать в инструкциях. Нашел описание «Клиент СЭД. Руководство администратора», но про восстановление там написано:

Восстановление резервной копии базы данных производится с привлечением администратора сервера СЭД. Более подробную информацию о последовательности действий при восстановлении клиентской базы данных можно найти в руководстве администратора сервера СЭД.

Полез искать руководство администратора сервера СЭД, нашел его на сайте казначейства Московской области. В двух словах, восстановление делается в диктмане (поэтому и серверная инструкция) «Сервис→Импортировать файл» выбираем полученный в процессе архивации файл и ждем. Там еще много нюансов описано, про повреждение базы например.

Начал восстановление минуты через 3 получил сообщение, что файл поврежден. Сделал еще раз архивацию, потом восстановление и опять та же ошибка и в том же месте. Вот тогда и решился на штатный экспорт диктмана, полезная вещь для бэкапа одной или нескольких таблиц. В «Структурах таблиц» выбрал все (Ctrl+A) — ПКМ — «Экспорт в файл».

Итак экспорт запущен, примерно в 9:00 – 9:30 утра, к концу рабочего для было 78%, очень долго висел на таблице KCSRNEW, целевые статьи, поэтому оставил в ночь. Это был первый день.

Кстати, именно то, что он так долго висел на таблице целевых подвигло на новое исследование и новую статью по этому поводу – Активный фитнес для СЭД-а.

Утром все уже было завершено. Файл all.eif, я так обозвал. К слову при архивации из клиента сформировался файл *.bck, хотя внутренне они они и похожи, есть мнение, что инструкция устарела или режим архивации изменили в клиенте.

Теперь чистка. В диктмане, в структурах таблиц снова выбираем все таблицы – ПКМ – «Создать», обязательно снимаем галочку Копировать данные таблиц, жмем «ОК» и ждем. 5 минут и делаем усечение, вот тут-то размер базы наконец уменьшился, да еще и как! База стала 57М, но пустая ведь. Я не был уверен, что усечение поможет и был готов создавать заново базу по инструкции, но решил проверить 20 минут не особо сыграли бы.

Теперь надо загрузить наш файл в пустую базу. Не стал делать «как показывали» – «Открыть файл импорта» и потом перетаскивать. Такой способ хорошо для выборочного переноса, да и хотелось проверить импорт из меню «Сервис». В общем делаем  «Сервис→Импортировать файл» выбираем наш экспортированный файл (*.eif) и ждем. На вопросы про перезапись, отвечаем утвердительно. Восстановление заняло в разы меньше времени: часа 3-4 всего, относительно экспорта конечно.

После окончания – ура-ура, все заработало! Хотя это и было предсказуемо, но после суточной возни – большое облегчение. И самое главное размер базы был как раз примерно 1.1Г, что равнялось первоначальному объему данных.

Все таки sp_spaceused- мега полезная вещь, людям с базой на аксесе явно не доступна такая функциональность, а для выяснения к каком именно месте базе надо худеть – это незаменимый инструмент.

ЗЫ. Решение укладывается в два предложения, просто хотелось описать ВСЕ, что я делал. Какие шаги и к каким результатам они приводили. Но описывать события спустя 3-4 дня тяжело, поэтому возможно получилось немного путанно.

Комментариев нет

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.