Загрузка больших файлов в Лоцман

[Askell]

Столкнулись с проблемой описанной в http://sd.ascon.ru/otrs/public.pl?Action=PublicFAQZoom;ItemID=319;ZoomBackLink=QWN0aW9uPVB1YmxpY0ZBUUV4cGxvcmVyO0NhdGVnb3J5SUQ9ODtTb3J0Qnk9RkFRSUQ7T3JkZXI9RG93bjtTdGFydEhpdD0x; "Stream read error" при возвращении в базу файла объемом более 90 Мб
Оперативы и дискового пространства на серверах достаточно, файловые архивы не используются. Смущает фраза "Существует ограничение ADO/OLEDB (интерфейс MS SQL Server): при работе с файлами требуется непрерывный блок памяти размера соответствующего файлу, который не всегда доступен в системе (даже небольшого размера) - это зависит от степени фрагментированности оперативной памяти." однако не нашел как на это повлиять.
Кто нибудь сталкивался с подобным? Во что упирались? Где копать: на сервере приложений или сервере БД?

[Chaa]

Единственный способ - использовать файловый архив. В него без проблем помещаются файлы до 2 Гб (возможно, в новых версиях и больше можно, не проверял).

[Askell]

Тоже верно. Понятно что это как-то негуманно запихивать в базу такие файлы. Другой вопрос, что не понятно из документации, как сервер приложений решает куда сохранять файл. Или если есть файловый архив, то все новые файлы автоматически туда сохраняются? И потом только вручную их туда-сюда пермещать?

[Chipollino]

В документации как раз чётко описано:
Если есть хоть один файловый арив с достаточным свободным местом для записи файлов - файлы будут помещаться в архив.

По поводу переноса - в оснастке ЦУК есть возможность переносить файлы из БД в архив и обратно по дате создания либо по размеру, так что можно раз в неделю запускать процесс переноса файлов малого размера из архива в базу.
Другое дело есть ли смысл? Мы давно используем архивы и проблем с ними не испытываем.

[Danila]

а как вы организуете при этом архивирование и бэкапирование-синхронизацию с базой данных?

так как получается, что файловый архив сам по себе, а БД - сама по себе..

[Chipollino]

Бэкапирование БД лоцмана - средствами SQL сервера (раз в сутки транзакции, а каждую субботу полная копия)
Файловый архив - средствами DFS между двумя серверами (один рабочий, второй резервный и синхронизируется в режиме реального времени).
Все сервера в качестве дисковой подсистемы используют RAID-10

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

[Danila]

Чуть не про это вопрос.
Как вы организуете соответствие бэкапа БД информации о файлах в таблицах FSOs с данными в файловом хранилище?


К примеру вы хотите откатиться на пару месяцев назад, чтобы найти файл - как вы найдете, если он был потом удален?

[Chipollino]

Никак - у нас такой необходимости откатываться и что-то искать нет.
Лоцман нужен для того, чтобы хранить в нём всю документацию утверждённую, анулированную и текущую в состоянии проектирования. Все варианты во время проектирования хранит у себя конструктор, поэтому откатываться куда-то для поиска документов необходимости нет - они или у конструктора, или никто не может их удалить.

Мне бэкапы нужны для того, чтобы восстановить базу после какого-либо глобального сбоя и несколько разных версий нужны для надёжности (вдруг последний бэкап будет кривой).

При желании можно делать и отдельные бэкапы файлового архива в тоже время, что и бэкап базы, но у нас архив уже перевалил за 50 гигов и делать несколько разных копий не хотелось бы.

Вообще в ЦУК есть возможность протестировать архив на ошибки и в т.ч. узнать - все ли файлы на месте (проверка по констролькой сумме CRC), а так же удалить лишние. Так что, если сумма файла или его имя не будет соответствовать записям в таблице - вам будет указан адрес где именно файл не найден.

[Danila]

Про удалить никто не может - знаем, плавали)))
У нас просто в Лоцмане еще и канцелярский документооборот (ОРД)...

Правда на уровне триггеров запретили сейчас удаление..
Но неопытные пользователи находятся всегда...

Храня файлы в БД - по логам всегда можно откатиться на нужный момент времени.

Но ваша ситуация ясна, спасибо.

Иногда тоже задумываемся над другой системой хранения файлов - но пока не видим необходимых нам плюсов.

[Chipollino]

Правильно разграничьте права и будет вам Щастье.
Можно ведь выставить на документ уровень доступа "Только чтение", а максимальный - "Полный доступ" и тогда только создатель документа и тот, кому он лично выдал право редактирования смогут этот файл удалить или изменить, а для остальных будет возможет только просмотр независимо от состояния.

Кстати, такие костыли на уровне тригеров SQL могут превратиться в грабли при переходе на следующую версию - лучше используйте обработчики серверных событий (настраиваются в конфишураторе).

[Danila]

это все мы знаем. с КД проблем нет.

Но в Лоцмане у нас ведется огромный пласт дополнительной организационно-распорядительной документации, а она таким жестким правилам и ограничениям не подлежит, по смене состояний и т.д.

собственно мы и сделали проще - запрет на уровне БД через триггер, так как система конфигурации таких более широких возможностей не дает...  хотя там есть некоторые близкие возможности, но мы их использовать не стали... это про серверные события...

костыли небольшие - если все документировать.

но вопрос реализации - да, возможен и там, спорить не буду)))

Но у нас были случаи, когда было недостаточно возможностей этих серверных событий. И есть некоторые другие особенности построения и разработки наших модулей, задачи которых не закрываются этими событиями.

Потому только так...

[Chipollino]

Ну если с правами совсем никак - делайте бэкап файлового архива в дни создания логов транзакций только на дозапись новых файлов

Код Выделить Развернуть

xcopy \\server1\archive \\server2\backup\ /d /e
а каждую неделю начинайте новый бэкап архива вместе с полным бэкапом базы.

Синхронизация до минут там всё равно не нужна, так что ночью будет запускаться по расписанию бэкап на sql-сервере и по шедуллеру на файловом архиве соответствующий батник