Загрузила не ту базу в 1с
Всем привет. Эта тема очень важна, так как она помогает восстановить информационную базу с вашего компьютера, если вы вдруг случайно ее удалили из списка информационных баз или удалили саму программу, так как учебная версия может очень часто ломаться и глючить.
В этой статье (уроке) я вам покажу как сделать восстановление и дальнейшую работу с ИБ.
Если что-то непонятно или хотите узнать, вы всегда можете подписаться на мой канал или вступить в группу, которая создана специально для обучающихся (ссылки можно найти ниже).
Восстановление информационной базы происходит очень просто. В данном случае, это скорее не само восстановление ИБ, а восстановление к ней доступа, так как она находится у вас на компьютере и просто вы наверное об этом не знаете (по крайней мере точно не все знают).
Когда мы открываем окно запуска платформы (Рисунок 1) и добавляем новую ИБ, то по умолчанию платформа создает папку в следующем месте "Диск С. Документы".
Найдите у себя эту папку и там вы увидите у себя то количество папок, сколько раз вы создавали информационные базы (Рисунок 2)
Вот с помощью этих папок мы и можем восстановить доступ к нашему приложению.
Скорее всего, у вас будет 2 такие папки, так как на уроках мы создали только две ИБ (одна основная, а вторая резервная и в нее мы загружали файл с расширением ".dt").
Как выяснить какая именно нужна папка? Нужно посмотреть на ее дату и постараться вспомнить когда именно вы работали с программой (или же пробовать все по очереди).
Перейдем к практике. Откроем окно запуска платформы и нажмем кнопку "Добавить". В новом окне выберем "Добавление в список существующей ИБ" (Рисунок 3) и нажмем "Далее"
В следующем окне дадим имя "Восстановление" и нажмем на многоточие, чтоб там выбрать папку с информационной базой. Нужно выбрать папку "InfoBase1" (Рисунок 4) и нажать "Выбор папки"
После этого нажать "Далее" и "Готово". как только нажмете "Готово" у вас автоматически выйдет предупреждение (Рисунок 5). Нажмите "Да"
После этого она появится у вас в списке (Рисунок 6)
Это предупреждение было о том, что у вас в списке уже есть ИБ, которая подключена к этой папке и это означает, что их две, которые будут мешать друг другу.
Выделите ИБ "Восстановление", нажмите на кнопку "Конфигуратор" и убедитесь в том, что вы действительно подключились к папке.
Этот способ работает тогда, когда вы случайно из главного окна удалили свою ИБ или удалили саму программу, то вы всегда сможете к ней подключиться, так как при удалении из списка и при удалении программы, все папки "InfoBase" остаются на диске с по пути "С. Документы"
Вот вы узнали еще один способ работы с платформой. И это только начало, самое интересное даже не начали.
На этом закончим, чтобы вы смогли усвоить то, что мы только что прошли.
В следующей статье будет тема "выгрузка ИБ в разных форматах" , а потом перейдем к работе с новым объектом дерева конфигурации "Справочники". Все это и многое другое на канале "GeekRazrab"
Всем спасибо. Задать вопросы, которые у вас возникли вы можете, написав комментарий или вступить в группу и задать там свой вопрос. Ссылка для вступления в группу - t.me.Apiscourses
Гуру 1С и Mysql, выручайте советом.
Есть сервер 1с 8.2 + сервер Mysql 2012.
Ошибочно загрузили дт-шку не в ту базу, через Конфигуратор.
База была тестовая, но как оказалось, важная. Резервные копии, конечно, нигде не велись. Образ сервера с mysql не делался.
Можно как-то откатить состояние базы до залития бэкапа?
а если мсскуль и не велись бекапы - то думаю и не влеся бекап скулевыми средствами.. так что скорее всего никак
когда только начинал одинэсить - сам такое сделал - хорошо был архив - потеряли всего пол дня работы - а так - аминь базе.
мне говорил один знакомый - есть такой лазерный считыватель, несколько лямов стоит, восстанавливает перезаписанные сектора на диске, даже по нескольку раз, ничего от него не спасет, диск может быть подгоревшим, затопленным, поцарапанным, только прессом можно уничтожить информацию. я ему не верил, конечно, пока он с затопленного диска базу не вытащил. хотя лично я не держал этот диск, так что верить ему на слово как-то стремаюсь, он тот еще лиздобол
(21) Ну, таких баек я не слыхал. Слыхал, что есть стенды, умеющие восстанавливать инфу по остаточным шлейфам (микронеточностям позиционирования головки при записи в рамках допусков). Именно поэтому стандарты программного уничтожения информации предусматривают многократную перезапись случайными последовательностями. Но даже на таком оборудовании восстановление сложных структур данных больших объемов типа затертой SQL-базы - нечто из области фантастики, ИМХО.
Если полная модель восстановления - то шансы должны быть.
Если готовиться зараннее - то уж точно.
(21)Восстанавливать информацию с магнитных дисков лазерным считывателем это нечто новое.
(23)Стенды есть и это не фантастика. Разумеется дорогие, точнее нереально дорогие, и разумеется не в свободной продаже.
Но тут надо понимать что восстанавливают эти стенды - огромное счастье если с диска можно будет вытащить процентов 30 файлов.
Причем естественно все эти файлы будут битыми.
Но это уже лучше чем полный ноль.
Отдаешь эти битые файлы команде аналитиков, те тратят сотни две, три человекочасов пытаясь собрать мозаику и в итоге выдают более менее достоверную гипотезу о содержимом нужного файла.
Вот это и подразумевается под словом восстановить информацию.
А все почему то думают что они работают по принципу - сунул диск в аппарат, через пять минут вытащил, и вуаля у тебя точная побайтовая копия того что было на диске три года назад.
(21) Там, насколько я знаю, не лазер, а какой-то специальный элемент, типа датчика Холла, который снимает намагниченность с поверхности.
Не стоит забывать, что по гистерезису можно определить, какое прошлое состояние намагниченности было.
Теперь, если диск затёрт нулями, то вероятность восстановления велика, так как нули поверх единиц будут немного отличаться от нулей поверх нулей.
Что касается SQL-сервера, то в процессе обновления базы он мог несколько раз сделать запись в одно и то же место, так как структура в процессе изменялась, так что помимо того, что мы сможем узнать предыдущее состояние (а может быть - два), нужно быть уверенным, что они отражают состояние до обновления, что маловероятно.
(24)[Если полная модель восстановления - то шансы должны быт]
dt загружается в булк-режиме, если тебе этот термин не знаком - погугли
(28) Ну, если транзакции не пакетами идут, а всё сразу (по-умолчанию, написано, что BULK-INSERT делает одну транзакцию), то что-то можно посмотреть.
Если же разбили по пакетам, то - "уже всё".
если есть бэкап этой базы на любой момент времени перед заливкой, даже самый древний, то можно восстановить
(31) Знаешь, BackUp-ы тестовой базы - это очень и очень редко.
Потом, тестовых баз - десятка два, потом сиди и ковыряйся, пытаясь понять, а где же мои чудесные доработки обитают - переписать иногда бывает быстрее, если помнишь, как делал.
(0) без фулбэкапа sql или dt никак. Только пользователей успокаивать.
1.Тестовая среда может рухнуть в любой момент или может быть перезалита, это нужно донести до тех кто в ней ковыряется.
2. Если нужно сделать что-то важное (например, снимок базы перед сдачей бух баланса, в котором еще потом что-то еще кто-то наковырял) - создается отдельная резервная база для группы или на каждого юзверя своя
3. Если сведения очень важные - нужен сиквельный бэкап
4. Если юзвер истерит (у меня бывали похожие ситуации) - шли накер. Ибо:
5. Нужно предупреждать - не предупредили значит никому не нужно, поднимается база на точку отсчета и юзверь набивает руками все заново
6. Самое важное это рабочая база.
7. Истерику надо лечить и вообще, на работе должна быть рабочая атмосфера.
Ну и в дополнение скажу еще вот что: если нет регламента (не расписаны процедуры, указы, инструкции) - значит ничего не было и не нужно никому.
Когда во франче работал, наши бывшие клиенты перепутали выгрузку данных и загрузку, и вместо создания бэкапа загрузили в рабочую древнюу копию. Бэкапов свежих конечно не было у них, база файловая. Пришлось им руками перебивать всё.
(0) скажи базе, давай, до свидания..
(37) Тестовая среда может рухнуть в любой момент или может быть перезалита, это нужно донести до тех кто в ней ковыряется. >> яростно плюсую
(32)Вот в этом то и дело.
Если информация в базе важна - делают бэкапы. Пофиг тестовая или рабочая она.
Если в базе бардак, и проще сделать заново, ну действительно нафига бэкапы. Никто не огорчится если базу сотрут.
ТС, MS SQL умеет восстанавливать базы на нужный момент времени. Откатишь на время перед загрузкой. Кури команду RESTORE, ключ STOP AT. А лучше позови специалиста, пока в шоковом состоянии еще чего-нибудь не поломал.
ТОже не понимаю истерии с dt. С 2006 году бекапы через dt делаю. Постоянно приходиться восстанавливать по разным причинам. Проблем нет.
Размер dt 3 Гига
(0) потому-что сама 1С писала письмо, что dt нужно делать для переноса баз, а более правильно средствами БД или папку целиком (если файловая). Так больше вероятности, что бэкап не превратится в тыкву
(14) "механизм предназначен, прежде всего, для получения образа информационной базы независимо от способа хранения данных." Точка.э
(17) запятая, э. читай внимательно. что dt нифига не гарантирует, а только является средством конвертации из файловой в серверную и наоборот
(17) Там дальше продолжение: "Использование этих способов [отличных от dt] дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы. Например, если в базе данных есть нарушения, то при выгрузке некоторая информация может быть не выгружена, в то время как при копировании будет сохранена вся информация, и после восстановления можно будет выполнить исправление базы данных."
"Использование этих способов дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы. Например, если в базе данных есть нарушения, то при выгрузке некоторая информация может быть не выгружена, в то время как при копировании будет сохранена вся информация, и после восстановления можно будет выполнить исправление базы данных."
Они уже официально оговорили, что все на страх и риск пользователя :)
Я делал раньше бекапы файловой в dt. А потом они у меня совсем не захотели загружатся в тяжкий для меня момент. Больше я в dt не бэкаплю. Такая грустная история((
(19) С другой стороны, бывают ситуации, что эти нарушения можно лечатся только выгрузкой/загрузкой *.dt. Так что, тут бабушка надвое сказала.
(22) Есть такое. Но бэкап средствами СУБД (или копирование папки файловой базы) сохраняет исходное состояние базы, а загрузка/выгрузка это состояние меняет (как минимум, не сохраняются данные индексов). В случае сбоя всегда лучше изменять данные по минимуму -- так больше шансов что-то вытащить
Если в СУБД косяк с итогами, то выгрузка/загрузка изменит картину: восстановленная база из dt не будет точной копией, а иногда это необходимо (например, баланс уже сдан с "кривыми" итогами и надо сделать копию в том же виде для разборов)
(0) dt использую для загрузки в тестовую базу для разработки/доработки и пр.
Ну и для бэкапа, каждый день.
Но главный бэкап это конечно же средствами скуля.
(34) Франч? На повременке? У меня база 120 гигов. Выгрузить в дт/загрузить из дт сколько времени будет занимать?
(36) нет, я фикси в молодой строительной фирме. Мне пока можно делать dt :) Размер его пока что ~ 800 метров
(35) Да не завожусь я :)
Например (32). Смысл архивной копии: В случае сбоя поднять базу в том же состоянии, в каком она была на момент бекапа. Так же важно время, за которое можно отресториться в случае сбоя.
(38) Ну, у меня не все базы такого большого размера. :)
(39) А из dt - не поднять?
Я понимаю, что выгрузка изменяет (те же индексы). Но в случае сбоя - так ли уж важны индексы?
На стройках кирпичи не каждый день на головы падают, и даже не каждый год. Но это не отменяет каски. Так и с dt - у кого-то может с 2000-го года всё быть в порядке, а у кого-то и через полгода может случиться косяк в базе, который не даст восстановить бэкап из dt. А вот обычный архив папки с базой (в файловом варианте) будет проще восстановить.
(46) При загрузке из дт, как минимум, пересчитываются итоги. Дальше, думаю можно не продолжать.
Пруфа нет.
(47) (48) ааа, извиняюсь! не так понял.
Я прочитал как "обрАботка может поплыть" )))
Думаю, нихренасе, внешние обработки может исказить)
(49) Выше писала: у был один раз форс-мажор - не загрузился dt. Но там и база была подыхающая. Один раз это какой процент?
(52) "Основным недостатком такого способа создания резервной копии является необходимость использования однопользовательского режима для осуществления этой операции. При большом объеме информационной базы перерыв в работе пользователей может быть достаточно велик, что не всегда приемлемо." - для меня в этом проблемы нет.
(53) Что ж вы все дальше не читаете-то? Я еще раз могу повторить: "Использование этих способов дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы". Еще проще -- если восстановиться из бэкапа скуля, его еще можно испортить загрузкой/выгрузкой. А вот обратное уже не работает.
А я считаю так: кто хочет делать бэкапы в dt, пусть делает. Ну если не учит чужой опыт людей и рекомендации производителя ПО им тоже ни о чём, то что тут поделаешь.
Да не загружается dt вот и всё! (в случае битых баз), а чтоб не битые были надо ТиИ а перед этим бекап. У меня один раз не развернулся. Опыту.
Для тех кто в танке (ну то есть на документацию) на Большой Партнёрке Нуралиев сказал (вольно к тексту): dt - для переноса из файлового в серверный и наоборот, бекап в файле (тока файл 1CD, в монопольном доступе) в сервере средствами СУБД. Всё!
(5) Не знаю что там с вашими обезьянками, а я лично сталкивался со случаями отказа восстановления БД из dt по меньшей мере дважды.
А дальше можете хоть обделаться, рассказывая как 100500 миллионов раз вы выгружали и успешно восстанавливали базы через dt-шник.
Никакие самые авторитетные мнения не смогут заменить личного печального опыта в таком вопросе.
PS. Лезьте за своим бананом. Я вам мешать не стану.
(58) Аналогично. Работало, работало. А потом бац и перестало загружаться. Хорошо резервирование настроено другими средствами. Надо было рядом копию базы сделать, но не удалось. Всему виной было превышение размера внутреннего файла.
(0) Даже не принимая во внимание страшилки про незагружаемые dt, SQL быстрее же и выгонять никого не надо, не?
А вот интересно, для тех у кого файловая, архивный копии тоже через DT выкручивают или все-таки архиватором непосредственно каталог базы или файл базы архивируют?
Я лично делаю так, как доступно. Если прав админа на сервер у меня нет, а бакап нужно делать, то выгружаю в DT, чтоб можно было без сервера на локальной машине поднять. Но для очень больших баз или для тормозного сервера таким методом не получится. Не говоря уже о том, что "битые" данные DT не лечит, а окончательно убивает.
(0) Сможет так случиться, что в файловой верии размер одной таблицы базы превысит 4 Гб. Соответственно, в этом случае, выгрузка пойдет болтом.
Про скульные бекапы, гут да. Но нужно один раз поморочиться, если бекапы нужны ежечасные, покурить все эти транзакшн-логи и т.д.
Насколько я понимаю, что видел у продвинутых людей, разностные бекапы делаются не только на уровне SQL, но и самим акронисом всего сервера СУБД. На тот случай, если совсем все плохо станет ;)
(0) 1.Если база файловая - быстрее скопировать, если серверная - быстрее сделаит бэкап средствами базовода.
2.с вероятностью до 1% база из DT не будет восстановлена.
(5) В отчете SQL размер временных таблиц превышает 4 Гига? У нас превышает и не грузится. Таблица регистра версионирования.
Единственный плюс копирования всей файловой базы это журнал регистрации
А дт это по сути сначала чекдбф а потом зип
Ничего нежелательного нет.
Можно спокойно выгружать базу в dt.
Главное архивы с помощью такой выгрузки не делайте.
(64)Архивные копии всегда делают средствами СУБД.
Если sql - значит средствами скуля.
Если файловая - значит средствами файловой системы.
1)делается теневая копия диска содержащего файл 1с.
2)монтируется теневая копия и файл упаковывается архиватором.
3)файл отсылается в место хранения, и формируется отчет.
(51) Вы матстатистику и теорвер будете финику, гендиру и главбуху объяснять, когда бэкап базы не взлетит за день до сдачи отчетности и компания влетит на штраф в десяток-другой лямов :)
В вопросах бэкапов вопрос не в том, что МОЖЕТ НЕ произойти, а вот, что МОЖЕТ произойти. Если вы не понимаете эту азбучную истину, то рано или поздно поймете на своем опыте.
Если из dt база не восстанавливается, то её уже нет. Возможно, давно. Поэтому и нужно выгружать в dt, чтобы база жила. Желательно её потом восстанавливать в файловую. Если очень большая, не получится.
(0) Потому что зачем делать лишние преобразования данных, причем теоретически могут быть проблемы при восстановлении из dt. Упакуй *.cd в zip и получишь примерно то же.
(0) По сравнению с backup MS SQL во-первых дольше как ВЫгружать, так и ЗАгружать, во-вторых появляется необходимость выгонять пользователей, в-третьих нет преимущества в объеме хранимых данных (сжатый backup, насколько мне известно, весит примерно столько же сколько dt).
(80) SQL - это не стандартно. Это не 1с. А dt - стандартно.И 1с гарантирует, что это всегда будет работать.
(79) и получишь нерабочую базу, так как выгрузка в dt гарантирует что в этот момент в базе никто не работает и не проводит документы или не сохраняет конфигурацию
нет, просто с 2006 выгружаю в dt и проблем не наблюдаю, в отличие от копирования cd файла, когда в этот момент юзверь проводит документ, или от копирования bak файла скуля, когда в нужный момент оказывается не та версия скуля, а какая там была никто не помнит
(90)Ну у каждого свой негативный опыт. Хорошо когда есть альтернатива.Поэтому не вижу причины, с упорством фанатика, заставлять всех переходить в свой лагерь и всех противников объявлять еретиками и призывать придать их анафеме
(91) Да, собственно, конечно есть.
Но в данном случае:
1. Делать копии файла 1CD рекомендует сама 1С.
2. Делать бекапы средствами скуля, а не выгрузкой в DT опять же рекомендует сама 1С. И более того, скулем можно делать выгрузку без выгона пользователей и автоматически. А вот в DT с выгоном и по праздникам.
(91) +1. Всё правильно сказал.
Я, например, не пытаюсь никого убедить в том, что архив в *.dt лучше/хуже других методов. Я просто говорю, что проблем с *.dt я ни разу не встречал.
Вообще, я считаю, что все эти проблемы с *.dt были на заре 1Cv8, но сейчас уже весь код платформы отлажен в этом сегменте и всё стабильно хорошо.
А переубеждать кого-то я не собираюсь - не вижу смысла. Каждый сам выбирает себе путь. Я себе уже выбрал.
Аналогично. Регулярно делаю дэтэшники, но естественно sql-сервер регулярно своими средствами бэкапит по плану.
(92) у скулевских бэкапов есть проблемка. не развернуть в файловом варианте на локальной машине для ковыряния :)
У кого-нибудь есть инструкция для чайника резервного архивирования средствами SQL во внешний файл, чтобы можно было спокойно брать вчерашний день и загружать в другой SQL в другом месте?
(96) примерно так, справедливо для MS SL2008 Express (не претендую на истину в последней инстанции):
1. делаем файлик, например BackSQL.sql со следующим содержимым:
BACKUP DATABASE [имя БД] TO DISK = N'E:\BackUpSQL\имя Файла архива.bk' WITH NOFORMAT, NOINIT, NAME = N'Понятное название латиницей', SKIP, NOREWIND, NOUNLOAD
GO
это же можно получить из SQL Server Management Studio, делай как больше нравится.
пишем bat файл:
start /wait osql -U -P -i BackSQL.sql
можешь добавить сжатие полученной копии в rar или zip.
Ставим его в виндовый шедулер с запуском, например, через каждый час. Получаем ежечасную, автоматическую копию базы данных, но тут есть одна особенность: файл резервной копии дополняется(. ) каждый раз, так что придётся выстроить механизм его перемещения вечером или сразу после создания, что-бы не вырос до безобразия.
Для полной версии можешь задействовать план обслуживания. будет несколько проще.
Для получения полной резервной копии всей БД:
rem Разделение даты на составляющие исходя из формата 20.10.2006
for /F "TOKENS=1,2,3 DELIMS=." %%a in ('Date /T') do (set day=%%a)&&(set mon=%%b)&&(set year=%%c)
rem set year=%year:~0,4%
rem set day=%day:~3,2% если есть ПТ 20.10.2006
net stop MSSQLSERVER
net stop sqlbrowser
net stop sqlwriter
start /wait %hom%\rar a -y %hom%\1\Full\%dt%-SQL-Buh %path1С%\ - забираем БД и файлы журнала
rem стартуем сервисы
net start MSSQLSERVER
net start sqlbrowser
net start sqlwriter
Обрати внимание: копии создадутся на том же диске что и сама БД, поменяй пути и настрой копирование куда-нить кроме как локальная машина.
Для начала хватит, а дальше сам разберёшься.
Здравствуйте. Не могу создать новую информационную базу.
Раньше проблем не было.
Сейчас при запуске нажимаю "Добавить", "создание новой информационной базы", далее пишет "Выберите поставляемую конфигурацию для начала работы или демонстрационный пример для ознакомления". А в окне, где нужно выбрать - пусто.
Что я делаю не так ?
В окне запуска 1С есть кнопка настройка. Там есть строка "Каталоги шаблонов конфигураций и . " добавьте каталог в который устанавливали 1с конфигурации. вида примерно такого C:\Program Files\1cv81\tmplts
1С8.3 базовая версия
Подскажите пожалуйста!
Хотела добавить вторую оргаизацию. Нажала на кнопку Добавить информационную базу, прошла по всем пунктам.
Выбираю ее, жму на 1СПредприятие и выдает мне: ЛИЦЕНЗИЯ НЕ ОБНАРУЖЕНА! . Получить лицензию или Загружить файл-ответ
Что делать-то надо?
Или базовая версия только на одну организацию рассчитана?
Заранее благодарю!
Базовая версия рассчитана на одну организацию в одной базе. Количество баз ничем не ограничено. Могу предположить, что новую базу вы создаёте из шаблона для профессиональной версии. Если другие базы (ранее созданные) открываются, то это скорее всего так. Если же лицензию требует при открытии любой базы, то у вас "слетела" лицензия. Получайте новую.
Здравствуйте. та же проблема.
Попытка создать базу новую. Мои действия
Скачала дистрибутив Бухгалтерия предприятия базовая, редакция 3.0; 1С: Упрощенка, редакция 3.0;, версия 3.0.31.13 , установила, запомнила каталог для шаблонов, Зашла в Настройки, указала каталог с шаблонами. Окно шаблонов- пустое ,к сожалению. смущает то, что нет там ни файла ни папки tmplts , только C:\Program Files\1cv82
Помогите, пожалуйста. что я делаю не так?
С техподдержки можно скачать только дистрибутив обновления. Новую базу из него не создать. Для создания баз нужен полный дистрибутив. Его можно взять либо из коробки, либо попросить у франча.
А что по поводу добавления новой базы? Может я как раз не могу и добавить, потому что идет привязка к сайту?
Я могу предположить, что вы пытаетесь создать базу из шаблона профессиональной версии. Проверьте:
1. Шаблон должен находиться в папке . \tmplts\1c\AccountingBase\
2. В файле . \tmplts\1c\AccountingBase\. \ReadMe.txt в первой строчке д.б. написано: 1С:Бухгалтерия 8. Базовая версия.
Если у вас есть пин-код из 16-ти цифр, а в поле для активации можно ввести только 15 символов, то нужно обратить внимание на следующее:
пинкод для активации ПРОФ версии состоит из 15-ти символов (5 групп по три символа в группе),
пин-код для активации Базовой версии состоит из 16-ти символов
у Базовой и ПРОФ версий один "движок" 1С, и какой пин-код запрашивать, 15 или 16 символов, 1С определяет по конфигурации базы данных, активация которой производится. Т.е. если платформа при активации определяет активируемую конфигурацию как Базовую, то запрашивает 16 символов, во всех других случаях - 15 символов.
Был летний солнечный день и ничто не предвещало беды, когда зазвонил телефон и сотрудница на другом конце сообщила: "Похоже я убила базу клиента". После допроса с пристрастием выяснилось следующее: на обычном удаленном рабочем столе (RDP) проводилось обновление конфигурации с реструктуризацией базы, таких обновлений делается по тысячу пятьсот раз на дню. Однако, в этот раз пошло, что-то не так и база данных рухнула.
и после этого вываливалась в Windows. Наличие резервной копии позволило бы восстановить базу в два счета, но человеческая беспечноть сотрудницы, которая не потратила лишних пару минут для ее создания привела к тому, что исправление проблемы заняло около четырех дней, было сделано несколько неправильных шагов, которые не приводили к значимому результату. Ниже я описываю правильный путь.
Восстановление базы
Поиск по интернету привел к страницам с описанием данных проблем без наличия решения, однако вскоре были найдены две важные ссылки, которые явились отправной точной в восстановлении:
Шаг №2. Делаем выгрузку конфигурации при помощи утилиты Tool_1CD
Шаг №3. Анализируем структуру файла испорченной базы
Итак, как вам известно CD файл - это по сути хранилище файлов-таблиц. Открываем Hex редактор (например опенсорсный Лирическое отступление
Все адреса хранятся в абсолютной адресации, что затрудняет исправление в ручном режиме, в случае если испортилась какая-то таблица не первая по списку. С другой стороны это упрощает программистам 1С работу и ускоряет процесс заргузки нужных таблиц в память.
Итак взглянем на таблицу из HEX редактора:
Upd 10/10/2012
Важное замечание awa :
1С обращается к таблицам по имени, и ей не важно, какая таблица находится в списке первой, какая второй и т.д. Просто при создании новой базы 1С создает нужные таблицы друг за другом в том порядке, в каком это создание написали программисты 1С. Поэтому всегда и получается, что CONFIG идет первой, CONFIGSAVE второй и т.д. Но если бы первой таблицей была бы какая-нибудь _REFERENCE152, а CONFIG была бы семнадцатой в списке, 1С спокойно бы работала с такой базой.
Шаг №4а. Загружаем в пустую конфигурацию выгруженную конфигурацию (извините за каламбур)
Загрузили. Записали. Смотрим в HEX-редакторе
Так-с, что-то не то, какая-то новая таблица добавилась. Отсюда вывод: Восстановление нужно делать на том же релизе платформы, что и испорченная база.
Шаг №5б. Загружаем в пустую конфигурацию выгруженную конфигурацию той же самой версии платформы
Да-а, результат тоже не очень. Таблица CONFIG заканчивается по адресу 0x10FFF, судя по всему она не реструктуризирована. Ладно попробуем скопировать рабочую таблицу Tool_1CD в нерабочую базу. Выделяем блок в рабочей базе и копируем с замещением по адресу 0x5000 в испорченную базу:
Открываем Tool_1CD, открываем испорченную базу, но увы Tool_1CD виснет при попытке посмотреть таблицу CONFIG. После нескольких не правильных шагов, мне пришла идея: а что если 1С структурирует таблицы при загрузке базы? Тогда остается сделать выгрузку и загрузку базы с рабочей конфигурацией.
Шаг №5в. Загружаем в пустую конфигурацию выгруженную конфигурацию той же самой версии платформы, делаем выгрузку и загрузку базы (не конфигурации!).
Посмотрим как сейчас выглядят смещения:
Уже лучше. Теперь CONFIGSAVE расположена по адресу 0x31FC000, что больше чем 0x31F1000. Как же скопировать больший блок таблицы CONFIG в рабочей базе на меньший блок в испорченной базе? Ответ прост: надо удалить метаданные в рабочей конфигурации, не влияющие на ее структуру: общие модули, картинки, отчеты, обработки и т.п. Нам важно запустить испорченную базу, конфигурацию мы потом восстановим.
Шаг 6. Итерация по удалению метаданных конфигурации, не влияющие на ее структуру, выгрузка и загрузка базы.
После нескольких итераций удаления, выгрузки и загрузки базы, я получил следующую картину:
Записываем. Открываем 1С. Отклично, все заработало.
Важное замечание awa
Как правило по смещению 0x4000, содержатся ссылки на файлы описания таблиц. А уже в файлах описания таблиц содержатся ссылки на таблицы записей, индексов и BLOB. В общем случае, если таблица CONFIG "начинается" с адреса 0x5000, а таблица CONFIGSAVE с адреса 0x31f1000 и нет никакой гарантии, что на промежутке от 0x5000 до 0x31f1000 не содержится ни одного блока, относящегося к любой другой таблице, помимо CONFIG. В большинстве случаев таблица CONFIG не фрагментирована, объясняется это, думаю, тем, что такое расположение файлов одной таблицы друг за другом, так, что вся таблица как бы находится в файле 1CD одним непрерывным куском, образуется в результате применения сжатия базы данных при тестировании и исправлении или при применении утилиты chdbfl.exe.
Осталось только загрузить в базу рабочую конфигурацию, чтобы восстановить рабочую базу. Все, База восстановлена.
P.S. Разумеется данный случай описывает исправление простых поломок, однако даже такой простой случай может ставить в тупик опытных профессионалов, когда не существует типовых способов решения проблемы. Не забывайте делать резерные копии.
Читайте также: