"...Как лучше всего "разгрести"..."
Согласился бы, если бы не допускал по-неопытности других ошибок. Пойду другим путем - выгрузка в шейп-файлы, удаление сервиса, удаление пользователя sde (cascade естественно), создание пользователя sde и сервиса заново, создание необходимых пользователей-"загрузчиков", загрузка из шейп-файлов. Использование только ArcCatalog и комманд ArcSde (по-крайней мере, на начальном этапе, пока не изучил более или менее схему и принципы работы sde).
Вопрос 1: Как Вы думаете, нормально?
"...Для юзеров достаточно "create session"..."
Недостаточно.
"...unable to create logfile system tables..."
alter user test1 quota 10m on usr01;
Нет.
grant create table to test1;
Нет (хотя пара таблиц в схеме test1 при попытке подключения через ArcMap создались).
grant create sequence to test1;
Теперь все.
А проще было бы - так я делаю - для "векторизаторов" - connect и квоты в табличном пространстве по умолчанию для них; для "загрузчиков" - connect and resource (хотя, все-таки, в части ресурсов - это я либеральничаю).
Но это так, к слову. Вопрос был в другом, формулирую по-другому (2): нужно ли давать "загрузчику" (или "создателю" структур данных), какие-либо привилегии на объекты схемы sde, хотя бы привилегию references на какие-либо таблицы sde? Правильно ли, что при создании "загрузчика" данных я совершенно "не обращаю внимания" на схему sde и спокойно работаю с данными от имени пользователя, который "ничего не знает" про схему sde? Хотя, вообще, грузить данные получается, но вопрос - в правильности.
"...Напомните!..."
Ответил Григорий Кувшинников - тут же, в нашем диалоге - но, к сожалению, его рекомендации не помогли - может, у Вас есть идеи?
"...извиняюсь, цитаты на английском..."
Не извиняйтесь.
Не знаю, откуда взято, немножко экспрессивно - видимо у них там в "есри" - наболевшая тема ,-) но - должен со многими положениями согласиться. Впечатления перемежаю вопросами.
"...it becomes difficult to separate which tables belong to the Geodatabase schema, and which tables are data tables..." - согласен - уже путаю, где что. Думал над этим - не приходило в голову, что можно создавать данные под другим пользователем, видимо это настолько естественно, что в руководствах этого описывать не нужно (простите за язвительность, я сегодня тоже злой :-Е).
"второй" Management - полностью со всем согласен - пример с sde.states понравился, видимо из жизни ,) Единственное - "...only solution will be to restore from last backup..." Тут - вопрос (3): принцип восстановления в этом случае? Ведь табличные пространства не испорчены. Значит, мне нужно восстановить всю бд "на момент времени до" (остановившись на каком-либо архивном файле). Это значит, что все транзакции бд (а не только в схеме sde) будут "откачены" назад. С другой стороны, если параллельно с физическим архивированием я использую логическое (dmp-файлы), то - можно ли восстановить из dmp-файла только схему sde или нельзя, ведь, если я правильно понял, часть структуры географических данных, даже хранящихся в схемах других пользователей связана с объектами sde? Перефразирую вопрос - нужно ли восстанавливать ВСЕ, или можно импортировать только sde?
"Все три" sequrity - полностью согласен. Только "...to edit Metadata you must be the owner of the data..." - метаданные еще не начинал, не изучал, не использовал, вопрос по-пути (не критично) (4): они очень важны - метаданные?
"ArcSde->tb Sde = Oracle->tb System" - хорошее сравнение.
(5) Про таблицы sde_logfile и sde_logfile_data - можно кратко - что там? (во время сессий что-то копится, вечером пусто) и - не страшно ли их "потерять"? (они у меня в тех табличных пространствах, которые я отдаю по-умолчанию "операторам" и "векторизаторам", не храню в них ничего нужного, а следовательно, не архивирую их).
