Создание dt файла серверной базы данных! #493332

В любом учебнике по 1С написано, что что перейти с серверного варианта на файловый или наоборот нужно сделать выгрузку в dt-файл, а потом загрузить его в новую базу. НО! Имеется серверная база (размером 20 Гигов) и сколько я не пытался создать выгрузку в dt-файл - у меня ничего не получилось. Процесс вроде как идет, 1С-ка пыхтит, но проходит 30 минут, час, полтора...а РЕЗУЛЬТАТА НЕТ!!! Чтобы это значило?

ну 20 гигов ужать до 2-х примерно... время надо однако

а не легче со скуля выгрузить?

и Шринк базы скуля сделать тоже может не повредит

Кстати в свое время сталкивался с похожей проблемой - у клиента была скульная база, и ее dt весла 7 Гб что ли. А при попытке загрузки этой dt в файловую базу 1с-ка ругалась, что не может загружать dt файл объемом больше 4-х гигов

fat32?

2 это не проблемма, это объективная реальность, ее нельзя преодолеть.

2 что фат32?

хрень какая-то, выгружал в dt базу 9 гигов и загружал нормально 30 минут?? несколько часов будешь ждать) для интереса можешь открыть диспетчер задач - процессы. Вид - Выбрать столбцы, выбрать прочитано байт, записано байт и глядеть как циферки бегут)

файловая система фат32 не поддерживает размеры файлов более 4 гигов

Не пол часа это мало, запасись терпением и поставь на ночь выгружаться!

да вроде NTFS была, не помню точно уже. А ты на какой платформе 9-гиговую дэтэшку выгружал-загружал ?

2 плевать, главное что в файловой не может быть быть таблиц размером более 4 гиг, даже если НТФС

8.1

короче тупо ждать нужно :(

еще вопрос по "Шринк" есть две базы на сервере: 1) Основная база организации (УТ) 2) Моя тестовая база (РАЗРАБОТКА) на которой тренируюсь и тестирую обновки (полная копия первой за определенную дату) ТАк вот, захожу через менеджер SQL, открываю свою базу (Разработка), перехожу в "Задачи-Сжать-Файлы", выбираю "Журнал", указываю "до 10000" (до этого было 19000), нажимаю ОК - жду. В результате обрезка происходит, все великолепно! Произвожу теже самые манипуляции с основной базой и хрен тебе называется - журнал сперва урезается (скажем с 19000 до 17000), а как только процесс сжатия в менеджере заканчивается, то размер журнала подпрыгивает минимум на 500 метров (в данном случае до 19500 - 20000). ПОЧЕМУ? Пробовал делать сжатие после полной архивации базы (база архивируется автоматически каждый день) - результат тот же. ПОЧЕМУ?

Для ДТ-шника журнал транзакций урезать и не надо... MDF файл надо шринковать. LDF  - журнал, его шринкуй на рабочей каждую ночь после бэкапа, кода на T-SQL в инете полно... как то так)

что у тебя 20 гигов то весит? MDF или LDF?))

они примерно равны - 24 MDF и 19,5 LDF

Хочется просто места немного освободить и журнал почистить хотя бы до 10 гигов

после полного бэкапа скриптами журнал почти под 0 угасает... в поиск

раньше делал после бэкапа шринк LDF каждую ночь... проблем не было. Или просто базу в SIMPLE переведи

да вот я и читал, что после бекапа должен урезаться в 0, а нифига не выходит! может потому что делаю интерактивно через SQL-менеджер, а не кодами? Я читал, что "шринк" лучше все-таки кодами делать.

, не в СИМПЛ не надо. Эту тему я уже поднимад тут - решили после бурных обсуждений оставить в ФУЛЕ!

правильно читал, примеров в инете дофига. если в Симпл не надо - то нафига обрезать журнал транзакций?) он для того и нужен... нет журнала - считай что Симпл

а можешь поделиться скриптами и примерно алгоритм операций описать по шринкованию журнала?! КАК ты делал?!

я хочу его сократить! Журнал нужен чисто на случай "вдруг упадет" (пару раз уже бывали сильные глюки базы). Но хранить 19 гигов журнала это тоже много. я думал сделать прлную выгрузку базы, урезать журнад до 1 гига и пусть себе опять накапливается! идея была именно такой!

посик украли?)

*поиск

я пользовался чем то наподобие: Шаг 1: ОБРАТИТЕ ВНИМАНИЕ: Если целевой размер не достигнут, переходите к следующему шагу. Шаг 2: BACKUP LOG pubs WITH TRUNCATE_ONLY Шаг 3: transaction log будет усечён до заданного размера.

да я много чего находил, но лучше ведь использовать то ,чем народ пользовался и что работает 100%! чтобы без особых эксериментов!

шаг 2-3 сразу... у меня работало на ура. на 2005 скуле

база 30 гиг, выгружается минут 35, dt чуть больше гига

ну я полтора часа ждал - НЕ ДОЖДАЛСЯ :( попробую на ночь поставить!

может быть в целостности данных что-то не так. Сделай ребуилд индекс или ТиИ на крайняк.

Мэйтененсе планс отрой, и посмотри сделанные задачки по обслужэиванию базы... позапускай хорошие вещи, Типа ребуилд индекс, проверки базы, и т.д.

а на английском можно??? Просто с такими вещами я еще не сталкивался, а со словами "Мэйтененсе планс" или "ребуилд индекс" в гугл не полезешь!

а во время обеда делай не Ребуилд индекс, а Дефраг индекс и обновляй статистику (её можно и несколько раз в день обновялть). также на обеде и бэкап можно полный сделать, отключать не надо никого всё равно

maintenance plan. В гугл как раз и полезеш, он сообразительный)

еще вопросик - в чем разница между "оперативным" и "автономным" режимами базы?

Кстати, вот нашел скрипты: BACKUP LOG Razrabotka WITH TRUNCATE_ONLY Пробую их выполнять. Мне пишет SQL: Не удалось сжать файл журнала 2 (Razrabotka_log), поскольку суммарное число логических файлов журналов не может быть меньше 2. (строк обработано: 1) Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

BACKUP LOG Razrabotka WITH TRUNCATE_ONLY Только эти 2 запусти

- пробовал, не прокатывает. Тоже самое пишет!

ну в поиск, чот не встречал такой ошибки. У меня скуля щас под рукой нет где это делал

А еще вопрос. Ты запросы эти сами выполняешь в самом Менеджере SQL - "выполнить запрос"? или какой-то сторонний менеджер используешь? Я просто когда с базой Oracla работал, то ставил себе SQL-Navigator сторонний.

да, выполнить запрос просто... Когда по ночам обезания и т.д. логам делал - в Мэйтененс планы включал, в общее обслуживание базы

*обрезания

ясно, спасибо!