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

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

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

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

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

(4) fat32?

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

2(5) что фат32?

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

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

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

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

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

(11) 8.1

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

(3) еще вопрос по "Шринк" есть две базы на сервере:
1) Основная база организации (УТ)
2) Моя тестовая база (РАЗРАБОТКА) на которой тренируюсь и тестирую обновки (полная копия первой за определенную дату)

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

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

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

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

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

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

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

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

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

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

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

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

http://www.sql.ru/articles/mssql/03102701TransactionLogSQL2K.shtml
http://www.oszone.net/7793/

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

*поиск

я пользовался чем то наподобие:

Шаг 1:

DBCC SHRINKFILE(pubs_log, 2)

ОБРАТИТЕ ВНИМАНИЕ: Если целевой размер не достигнут, переходите к следующему шагу.

Шаг 2:

BACKUP LOG pubs WITH TRUNCATE_ONLY

Шаг 3:

DBCC SHRINKFILE(pubs_log,2)

transaction log будет усечён до заданного размера.

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

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

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

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

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

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

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

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

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

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

Кстати, вот нашел скрипты:

DBCC SHRINKFILE(Razrabotka_log,1000)

BACKUP LOG Razrabotka WITH TRUNCATE_ONLY

DBCC SHRINKFILE(Razrabotka_log,1000)

Пробую их выполнять. Мне пишет SQL:

Не удалось сжать файл журнала 2 (Razrabotka_log), поскольку суммарное число логических файлов журналов не может быть меньше 2.

(строк обработано: 1)
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.

BACKUP LOG Razrabotka WITH TRUNCATE_ONLY
DBCC SHRINKFILE(Razrabotka_log,1000)

Только эти 2 запусти

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

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

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

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

*обрезания

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