Большие растровые каталоги

Question

Приветствую профессионалов ArcSDE!
Имеется большой набор растров, который был загружен в raster catalog ArcSDE базы на SQL Server. Размер, занимаемый на диске растрами (формат - jpg) - около 15 Гб. При загрузке в каталог я получил прирост объема базы более чем на 60 Гб (расчет пирамид и статистики для растров был отключен, компрессия LZ77).
После этого возможность делать бэкапы свелась к нулю, так как они имеют огромный вес.
Как вы работаете с большими объемами растров в каталогах? Где можно почитать об этом?
И как грамотно чистить базу после удаления растрового каталога? потому что кроме таблицы имеющей имя растрового каталога создаются, как я понял, еще вспомогательные таблицы в базе.
Спасибо!

Answer 1

Я хоть и не профессионал SDE, но раз другие молчат - я скажу =)
Можно сделать отдельный экземпляр БД для растров, задать простую модель восстановления, чтоб журнал не распухал. Растры обычно обновляются реже вектора, соответственно и бэкапить всё это хозяйство наверное можно будет реже. Если не очень страшна небольшая потеря качества, то вместо LZ77 алгоритм сжатия стоит указать "жопег" обычный или 2000, поэкспериментировать с коэффициентом.
Как чистить я хз - я через ArcCatalog удаляю и всё
И я так понимаю, что сейчас активно продвигается решение на базе ArcGIS Server Image Extension. Файлы хранятся в исходном виде, не в SDE, но тем не менее обеспечивается централизованное управление. Свои плюсы, свои минусы, как вариант рассмотреть стоит.

Answer 2

думаю чистить ручками в кишках SDE не хорошая идея, раз  SDE сам создает дополнительные системные таблицы и соответственно сам должен их удалять грамотно, иначе это будет не достаток в системе
Все таблицы регистрируется в sde_table_registry, там можно посмотерть

Answer 3

Резервная копия делается стандартными средствами SQL. Но естественно, нужно иметь носитель соответствующего размера - дисковое хранилище или куча лент.
А если под операцией "почистить базу", Вы подразумеваете уменьшить её размер, то всё равно без создания "бэкапа" Вы её не уменьшите. В MS SQL Server эта операция называется shrink.

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