Dt файл не загружается
Наверное, редко можно встретить человека, который часто работает с программой 1С 8.3 и не встречался с окошком с надписью подобного рода: «Неверный формат хранилища данных ‘file://C:/Users/Alex1/AppData/Local/1C/1cv8/058t1m89-295c-47c4-8922-f67f568rf70e/Config/RuntimeCacheStorage’ «.
Чаще всего такая ошибка появляется при обновлении конфигурации, при открытии обработки, в конфигураторе и в других случаях. Причина кроется либо в нарушении целостности структуры информационной базы, либо — чаще — в кеше 1С.
- очистка кеша;
- исправление структуры базы данных;
- перенос данных в чистую, не «битую» информационную базу.
Исправление структуры базы данных
На данном этапе в первую очередь мы должны испробовать штатные механизмы тестирования и исправления базы. Это относится как к запуску соответствующего пункта в конфигураторе, так и запуску файла chdbfl.exe.
Но практика показывает, что эти механизмы не всегда помогают.
Получите понятные самоучители по 1С бесплатно:
Тогда поступаем следующим образом. Разворачиваем чистую информационную базу. Цель – получить файл конфигурации (с расширением cf).
Затем снимаем неработающую конфигурацию с поддержки и делаем объединение с сохраненным файлом cf. Если требуется, объединяем с восстановлением поддержки. Не забудьте перед этим действием сделать резервную копию!
Важно! При объединении с чистой типовой конфигурацией внесенные ранее изменения в Вашей конфигурации могут пропасть. Нужно будет добавить их вновь. Будьте внимательны!
Загрузка копии в пустую базу
Для начала создадим пустую базу. Нажмем кнопку «Добавить».
Отметим, что при переносе базы на другой компьютер, может вообще не быть других баз. В таком случае список в 1С будет пустым. В остальном порядок действий такой же. Ну и разумеется, нужно файл dt перенести на этот компьютер, например, на флешке.
Выбираем пункт «Создание новой информационной базы».
Выбираем пункт «Создание информационной базы без конфигурации…».
Можно создать базу и из шаблона, но это займет больше времени. Быстрее создать пустую базу, учитывая то, что на нее мы будем грузить копию.
Укажем название базы и папку для ее хранения.
Затем заходим в созданную базу в Конфигураторе.
Переходим в меню «Администрирование — Загрузить информационную базу».
Выбираем наш файл с расширением *dt и нажимаем «Открыть».
Нажимаем «Да» на предупреждение.
Через некоторое время база будет загружена.
Здесь нажмем «Нет», если не нужно заходить повторно в Конфигуратор загруженнной базы.
В итоге мы получим базу с данными из копии.
Перенос данных в чистую, не «битую» информационную базу
Создаем чистую информационную базу того же релиза, что и «битая», и с помощью обработки «Выгрузка Загрузка данных XML«, которую можно найти на диске ИТС, переносим данные в наверняка целостную базу. Здесь опять же повторюсь, что структуры баз должны совпадать, и если в Вашей базе есть структурные изменения, их сначала нужно добавить в чистую.
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
Пытаюсь развернуть DT рабочей базы на тестовой машине.
DT весит 9 Гб, а сама база примерно 110 Гб. База клиент-серверная, сервер на debian, стоит postgresql 9.6 и сервер 1С 8.3.13.1513 х64. Клиентская терминальная машина на Windows, на ней стоит 8.3.13.1513 х64.
Запускаю загрузку базы из DT, проходит 5 минут, база начинает весить 2,3 Гб и всё, выходит ошибка "В информационную базу загружены не все данные 1с. Ошибка формата потока"
Пробовал загрузить 4 разных DT-файла. Все вылетают с такой ошибкой.
В чем может быть проблема? Почистить кэш не предлагать))
(3) точно. DT был сделан с базы под платформой 1513 и разворачивается тоже на 1513, только на другом компе
(7) NAME TYPE SIZE USED PRIO
none virtual 6G 0B 0
Как понять сколько нужно?
(9) ТиИ не делал в источнике, надо чтобы все вышли часов на 8, а это проблематично.
Все 4 файла сделаны с одной базы, в разные дни. Но с базой вроде пока проблем не наблюдается
Если в базе есть ошибки, то она не загрузится из dt'ника
Все кто делает резервные копии - dt'никами сильно рискуют остаться без базы.
(12)[Все 4 файла сделаны с одной базы, в разные дни. Но с базой вроде пока проблем не наблюдается]
это тебе кажется
а что только я один не понимаю, зачем ему эту всю хрень нужно затащить на клиентскую машину, если ее можно и нужно развернуть как лишнюю базу на том же сервере и в нем тестить все себе интересное на сервере?
(33) а им не похрен где тестить? чего такого страшного в запуске теста на отдельной базе, ну пускай даже на том же сервере?
Вот соседняя ветка, уверяла Переход с Микрософта на Линукс что с postgres проблем нет, особенно с бекапами.
(36) я бы, пока суть да дело, а если есть готовые ДТ, то проверил бы из них загрузку в соседнюю базу на том же сервере, чтоб лобовым способом проверить, что проблемы в ДТ нету.
(35) Можно случайно перепутать тестовую базу и боевую. Можно неосторожним движением уронить процесс сервера 1С:Предприятия или SQL-сервера.
(39) (37) А что за отладчикофобия? Проверял специально, влияние параметра включенной отладки на сервере на производительность влияет на уровне погрешности. Конечно, когда процесс трассируется с подключенным отладчиком, это другое дело. Но повторяю, сам по себе признак разрешения отладки не мешает работе.
(47) Да, на самом деле оказался битый dt. Все 4 dt-шника, которые я пробовал загружать были сделаны скриптами. И все оказались битые. Выгрузил вручную через конфигуратор и загрузил без ошибок
(43) >> А что за отладчикофобия?
Это тема отдельно холивара. И даже если считать, что включение отладки не влияет на производительность (ну или пренебречь этим влиянием), остаётся проблема, когда разработчик начинает отлаживать процесс в боевых базах на продуктивном rphost-е. А этим грешат 99.9% разработчиков, где включена отладка на продуктиве.
(48) DT - не является резервной копией для клиент-серверных баз. Это аксиома. А зачем было доказывать аксиому.
(50) ну как бы у него аксиома получилась двоякая - ДТ вручную Конфигуратором работает, а хз откуда взятые скрипты создавали ДТ битый.
з.ы. И зачем нужно было годами делать как бы архивы, которые никто никогда не тестил на загружаемость ?
(49) точно! Если включил отладчик на продуктиве, то значит рано или поздно, так или иначе, но пользоваться им начнешь :-)
(52) Продуктив продуктиву рознь. В 90% случаев это допустимо. Более того, часто даже необходимо подключиться отладкой к пользовательскому сеансу, чтобы выяснить что там у него не так.
Я однажды sql profiler на рабочей базе включил и забыл закрыть. Полдня не могли понять, почему всё медленнее вдвое стало :)
(53) Для этого надо отдельную тему создавать. Из SQL база никак не хотела разворачиваться. Я выгружал бэкап рабочей базы через pgadmin, создавал новую базу в pgadmin на тестовом сервере, восстанавливал данные из бэкапа в эту новую базу, и через какое-то время pgadmin писал ошибку, что не удалось загрузить данные и большой список ошибок. Пробовал через pgadmin сделать копию 100% рабочей базы на том же тестовом сервере и восстановить её в другую базу на этом же сервере - те же самые ошибки (что то там про то, что не создан какой то оператор и какой-то не верный тип). Долго разбирался с кодировками и прочей хренью на линуксе, но всё было ок, русские локали работали и пустая база создавалась с русской кодировкой. Решил обновить postgresql с 9.6 на 10, но хрен там. У версии debian, которая установлена на серваке какие-то проблемы с новым 10-ым postgresql из-за библиотеки libssl.so
Короче понял, что без админов в линукс лучше не лезть, откатил всё обратно, попробовал вручную сделать бэкап рабочей базы и развернуть его. Чудом всё получилось. Дальше буду с админами разбираться что не так с бэкапами postgresql
(57) Что-то мне помнится, что для восстановления бэкапа постгреса надо сначала базу создать из 1с, а потом уже восстанавливать бэкап поверх существующей базы. Что-то там с определяемыми типами, которые создаются в контексте базы, и эти определения не сохраняются в бэкапе.
(57)[ те же самые ошибки (что то там про то, что не создан какой то оператор и какой-то не верный тип)]
дык это 100500 раз описано, да есть фичи
Что делать, если архив базы загружается в файловом варианте с ошибкой "Превышен максимально допустимый размер внутреннего файла", а загрузить очень надо? Постараюсь примерно описать технологию, которую нам удалось разработать при активном участии Виктора Сосновского из фирмы "1С" на партнерском форуме.
Предположим, вы сформировали архив базы и теперь пытаетесь загрузить его в файловом варианте. Сначала все идет хорошо, но в какой-то момент возникает ошибка:
"Ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине: Ошибка СУБД: Превышен максимально допустимый размер внутреннего файла 'D:\1CBASES\NewDB/1Cv8.1CD' "
Я лично потратил ОЧЕНЬ много времени на поиск решения этой проблемы и в итоге нашел его, что позволило нам создать файловую копию базы данных размером 18 Гб и в итоге сэкономило примерно неделю времени (могу в комментариях рассказать, как было дело, но сейчас речь не о том).
Итак, причин возникновения такой ошибки может быть несколько:
- Размер КАКОЙ-ЛИБО таблицы в базе данных превышает лимит для файловой версии (4 Гб). Если честно, во избежание подобных эксцессов мы проверяли размеры таблиц базы заранее с помощью обработки "SQL базомер" (или аналогов).
- Ошибка связана с глюком особенностями платформы, и вызвана определенной спецификой структуры метаданных выгружаемой конфигурации.
С первым случаем все понятно - если базомер показал превышение лимита по каким-то из таблиц базы, то эти таблицы необходимо почистить. Если речь идет о справочнике или непериодическом регистре сведений, то нужно постараться удалить оттуда ненужные элементы/записи. То же самое относится и к "тяжелым" документам с их табличными частями. В первую очередь следует заняться удалением помеченных объектов, конечно.
Регистры накопления - отдельная тема. Размеры таблиц итогов могут превышать размеры таблиц записей регистра, причем зачастую значительно. Иногда может помочь даже простой пересчет итогов.
Регистры остатков могут некорректно (не по всем измерениям) закрываться, что приводит к ОЧЕНЬ значительному и быстрому разрастанию таблиц итогов. Списание "зависших" остатков регистра накопления может при последующем пересчете итогов дать экономию до нескольких Гб, проверено на собственном опыте у "нерадивых" клиентов. ))
Что же делать, если каждая таблица вашей базы размером менее 4 Гб, но ошибка все равно возникает?
Это значит, что у вас второй случай - проблемная структура метаданных конфигурации. Вероятнее всего, ошибка возникает на этапе создания индексов.
В двух словах опишу ситуацию в целом, чтобы было понятно, словами Виктора Сосновского из 1С. Ниже цитата с партнерского форума:
"При загрузке информационной базы в файловом варианте сначала загружаются данные всех таблиц, а затем создаются индексы. Ошибка создания индекса приводит к тому, что индекс, созданный с ошибкой, и все последующие индексы не создаются. Если в базе много данных, то это приведет к существенному снижению производительности. Полноценная работа с такой базой будет невозможна."
Нужно узнать, какая именно таблица приводит к ошибке при создании индекса.
Включаем технологический журнал - в папку "С:\Program Files (x86)\1cv82\__НомерВерсииПлатформы__\bin\conf\" (или аналогичную, __НомерВерсииПлатформы__ подставьте свой) кладем файл logcfg.xml примерно следующего содержания:
Внимательно следим за тем, чтобы каталоги для дампов и логов:
- Существовали
- Различались
- Были доступны для чтения и записи тому пользователю Windows, от лица которого вы запускаете конфигуратор.
Перезапускаем конфигуратор (при этом включается технологический журнал) и заново пробуем загрузить наш .DT. После возникновения ошибки идем в каталог для логов, находим там файл лога, содержащий нашу ошибку, и внимательно читаем его.
Первое же вхождение EXCPCNTX в логе в моем случае указало на команду, которая вызвала ошибку: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR (у вас название индекса будет другое).
По цифрам из названия индекса с помощью обработки "Структура хранения таблиц базы данных" (или аналогов, которые умеют показывать индексы) находим, какой таблице принадлежит данный индекс. У меня это оказалась таблица оборотов одного из нетиповых регистров накопления.
А дальше начинается самое интересное - нужно попытаться угадать, что именно в структуре вашей таблицы приводит к ошибке индексации.
В первую очередь следует смотреть, какие поля входят в индекс. Как выяснилось, платформа ОЧЕНЬ не любит, когда совокупный размер ключевых полей индекса становится значительным. В частности, она не любит индексировать длинные строки - так, в моем случае в индекс попадало измерение с типом СТРОКА (500) и оно вызывало ошибку. Другой представитель фирмы "1С" высказался на партнерском форуме еще в 2007 году:
" Если длина ключа оказывается близкой к 2К, то начинается резкий рост размера индексов с рядом неприятных последствий. "
И действительно, в 2013 году ничего не изменилось - в подобных случаях наблюдается лавинообразный рост размеров индекса на файловой базе. А когда таблица индекса превышает лимит в 4 Гб, загрузка .DT останавливается с ошибкой.
Лично мне помогло отключить для проблемного измерения флажок "Использование в итогах", т.к. в реальности итоги по нему не требовались. Оно перестало попадать в саму таблицу оборотов и, как следствие, в индекс таблицы оборотов. Есть и другие способы - более строго ограничить размер строки, например. Читал, что некоторым это помогало.
Эти изменения необходимо применить к информационной базе, при этом произойдет реструктуризация вашей таблицы.
Если изменения внесены на SQL-копии базы, то после этого нужно заново выгрузить .DT и попытаться перезагрузить его в файловой версии.
Кому особо не повезло и ошибка вылезла снова - тому следует повторить сначала всю процедуру, начиная с анализа логов. Возможно, проблемная таблица была не одна, или вам не удалось решить проблему с размерами полей, входящих в индекс.
ТОже не понимаю истерии с 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С с расширением *dt — это файл, который можно получить при создании копии базы через Конфигуратор. С помощью него в дальнейшем можно восстановить копию базы. Рассмотрим подробнее, как работать с этим файлом, на примере программы 1С:Бухгалтерия предприятия.
Как получить файл dt
Зайдем в программу через Конфигуратор под пользователем с полными правами.
Откроем меню «Администрирование — Выгрузить информационную базу».
Укажем папку для сохранения файла и название файла, нажмем «Сохранить». Название файлу рекомендуем давать понятное, осмысленное, а не оставлять по умолчанию. Так будет проще ориентироваться, если файлов будет несколько.
Получите понятные самоучители по 1С бесплатно:
В итоге в папке будет файл dt.
Очистка кеша 1С
Порой достаточно удалить строку с наименованием информационной базы из списка, а затем снова добавить. При этом создастся новая, чистая папка для кеша. Часто таким способом пользоваться не рекомендую, так как папка со старым кешем остается и засоряет диск.
Как загрузить файл dt
Далее рассмотрим, как загрузить файл dt. На практике есть несколько частых сценариев:
- Переносим базу на другой компьютер.
- Продолжаем работать на текущем компьютере в имеющейся базе. Копия же нужна, например, чтобы поэкспериментировать.
- Текущая рабочая база нам не нужна, мы хотим ее заменить на копию.
В зависимости от этого немного отличаются дальнейшие действия.
В первом и втором случаях проще всего создать новую пустую базу и загрузить туда копию.
В третьем случае загружаем копию прямо на рабочую базу.
Загрузка копии в рабочую базу
В этом случае новую базу создавать не нужно.
Просто заходим в Конфигуратор той базы, которую нужно заменить на копию.
Затем выполняем описанные выше действия по загрузке файла dt.
Читайте также: