SDE and Oracle

0 голосов
спросил 09 Март, 03 от Erkesh (1,080 баллов) в категории Программные продукты Esri
Подскажите, кто знает точный ответ на следующий вопрос:
Можно ли переместить (перестроить) индексы пользователя SDE (в целях улучшения производительности работы БД) в другое табличное пространство - отдельно от пространства, где лежат таблицы этого пользователя. Важно ли вообще для работы ArcSDE, в табличных пространствах с какими ИМЕНАМИ (а возможно, и параметрами управления этими табл. пространствами - локально управляемые или управляемые из словаря данных, а также параметрами хранения) хранятся его индексы и таблицы?
Для чего SDE при установке создает пространство именно SDE - всего лишь для "удобства" написания установщика sde? Тогда почему бы на одном из шагов мастера установки не предоставить пользователю возможность ВЫБОРА табличных пространств? Возможно - ответы в документации - тогда нужна всего лишь ссылочка.

9 Ответы

0 голосов
ответил 12 Март, 03 от igorstr (6,660 баллов)
Место укладки всех таблиц можно прописать в таблице Oracle DBTUNE (лежит в схеме SDE). Табл. пространство SDE создается при установке ТОЛЬКО ДЛЯ СЛУЖЕБНЫХ ЦЕЛЕЙ. Данные и индексы должны лежать в пользовательских табл. пространствах. Если все валить в одну кучу - сами потом замучаетесь ЭТО разгребать если что-то навернется (ведь и диск может заглючить).
В ESRI сидят люди которые думают, что заниматься администрированием SDE будут администраторы, для которых написать SQL запрос в 20 строк - дело 20 секунд. К сожалению, реально это не так. Не обижайтесь, сам такой. Но в таком случае желательно прочитать документацию, хотя бы бумажные книжки. Да, они (пока) на английском, но кому сейчас легко?
ВЫБИРАТЬ табличное пространство при загрузке данных нельзя (в Oracle). Грузит данные юзер. А юзер на то и юзер, чтобы не задумываться про какие-то там табл. пространства, думать ДОЛЖЕН администратор и ЗАРАНЕЕ. Табличное пространство МОЖНО НАЗНАЧИТЬ либо через DBTUNE, либо через "табличное пространство пользователя по умолчанию". Естественно, класть данные надо НЕ ПОД юзером SDE. Он только СЛУЖЕБНЫЙ!!! Желательно раскидывать данные и индексы по разным табл. пространствам, лежащими на разных дисках. Если диск только один (физический) как ни разбрасывайте - толку большого не будет. Очень приличное описание организации хранения данных можно взять тут - http://www.esri.com/library/whitepapers/pdfs/multiuser_ai8.pdf. Почитайте, не поленитесь, жизнь станет гораздо легче.
По поводу DBTUNE можно еще почитать "ArcSDE Admin. Guide". А перед этим желательно и "Understanding ArcSDE".
0 голосов
ответил 20 Апр, 03 от Erkesh (1,080 баллов)
Давно не был. Увидел ответ. Спасибо.
Давно (но не с самого начала) использую dbtune (создал там свои "keywords"), но вопрос снять забыл, извините.
Доки по-английский читаю, это естественно для IT.
Multiuser_ai8.pdf - не знал, только что скачал, прочту.
С обоими из указанных Вами руководств уже ознакомился. Спасибо.
Теперь:
1. Как лучше всего "разгрести" по другим табличным пространствам то, что уже лежит в тп SDE и что нужно "разгребать" или, вернее, что нужно оставить? Там у меня кроме того, что было создано при установке еще несколько "географических тем" (называю по-старинке, извините).
Далее:
2. Это место в Вашем ответе - "...класть данные надо НЕ ПОД юзером SDE..." - не понял. Вернее понял, но - как назначить пользователю привилегии создавать темы и назначать привилегии другим пользователям? Т.е. я сейчас темы хотя и создаю в других табличных пространствах, но создаю их под пользователем sde. А как сделать так, чтобы создавать их под другим пользователем? Просто так - "взять и создать"? (только что попробовал (в первый раз - до этого и в голову подобное не приходило, использовал только возможности, предоставляемые keyword) - получается, но - правильно ли это?
и еще: мой вопрос "Кодировка" в разделе "семейства 8" про sde2shp не снят - можете прояснить?
0 голосов
ответил 21 Апр, 03 от Гость (210,080 баллов)
Пишите Ваше сообщение здесь
0 голосов
ответил 21 Апр, 03 от Гость (210,080 баллов)
Команда выполняется с командной строки. Как правило по-умолчанию стоит кодовая страница DOS(866). Поставь явно set NLS_LANG=AMERICAN_AMERICA.CL8WIN1251 перед выполнением команды
0 голосов
ответил 21 Апр, 03 от Erkesh (1,080 баллов)
Ошибка в кодировке - cl8MSwin1251.
Не суть важно - все равно не работает - см. форум на "семейства 8".
Григорий, давайте перейдем на тот форум, чтобы не дублировать.
0 голосов
ответил 21 Апр, 03 от igorstr (6,660 баллов)
....Как лучше всего "разгрести"...?
Удалить все данные и загрузить под новыми юзерами (со своими новыми табл. пространствами). Это просто. Можно изучить Oracle, SDE и перетащить (именно перетащить не удаляя) все данные не нарушая целостности БД.

...как назначить пользователю привилегии создавать темы и назначать привилегии другим пользователям
Для юзеров достаточно "create session", предоставлению прав на загруженные данные - через ArcCatalog правой кнопкой мыши.

..."Кодировка" в разделе "семейства 8" про sde2shp не снят
Напомните!

...класть надо НЕ ПОД юзером SDE...
Далее, извиняюсь, цитаты на английском:
Question
Should you load data as the SDE user ?


Answer
ESRI does not recommend loading data as the user "sde". Following are reasons why this is considered bad practice.

* Management. The SDE user owns the geodatabase schema. If you load data as the SDE user, it becomes difficult to separate which tables belong to the Geodatabase schema, and which tables are data tables. This makes management of the geodatabase difficult.

* Management. If you drop any of the Geodatabase tables from the SDE user’s schema by mistake, this will render the Geodatabase inoperable. The only solution will be to restore from last backup. If you are loading data and creating tables as the SDE user, it becomes easier to delete Geodatabase Schema tables by mistake. It also becomes possible to corrupt the Geodatabase when loading data. For example, there is a schema table named SDE.STATES. If you were to load the sample STATES.shp, if you ignored the error message and continued, the SDE.STATES table would be dropped, and you would need to recover the Geodatabase from backup.

* Security. The SDE use is the owner to the Geodatabase schema. To manage the schema, the SDE user may have high database administrative privileges, potentially giving the SDE user access to all data in the database. Treat the SDE user password as you would the database administrative password. Only give responsible users the SDE password. Minimize risk by minimizing the number of people that know the SDE user password.

* Security. Loading data as the SDE user potentially means more people will need to know the SDE user password.

* Security. In the ArcGIS 8.x architecture to be able to edit Metadata you must be the owner of the data. If the SDE user is the owner of the data, then you must give the SDE password to the user that will edit the metadata.

Question
Should I load data into the SDE user tablespace?


Answer
It is not recommended to load data into the SDE user tablespace.

- When you create the SDE user, the SDE user will have a default tablespace. The tablespace is designed for the storage of the ArcSDE and Geodatabase schemas. Loading data into the SDE user tablespace is the same to ArcSDE as loading data into the SYSTEM tablespace is to Oracle. It should be avoided.

The storing of spatial data in the SDE user tablespace will lead to suboptimal performance of spatial data due to:
-fragmentation of the SDE tablespace
-its potential to crash the ArcSDE if the tablespace should fill up
-possible contention on the storage space

* When a user connects for the first time, the SDE_LOGFILE tables are created to store any user selection. It is not unusual for users to select 100K features. If the SDE user were to make this selection, 100K entries would be written to the log files, potentially in the SDE user tablespace. This should be avoided, as discussed above.
0 голосов
ответил 21 Апр, 03 от Erkesh (1,080 баллов)
"...Как лучше всего "разгрести"..."

Согласился бы, если бы не допускал по-неопытности других ошибок. Пойду другим путем - выгрузка в шейп-файлы, удаление сервиса, удаление пользователя 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 - можно кратко - что там? (во время сессий что-то копится, вечером пусто) и - не страшно ли их "потерять"? (они у меня в тех табличных пространствах, которые я отдаю по-умолчанию "операторам" и "векторизаторам", не храню в них ничего нужного, а следовательно, не архивирую их).
0 голосов
ответил 24 Апр, 03 от igorstr (6,660 баллов)
>>Вопрос 1: Как Вы думаете, нормально?
Именно так! Я бы вообще один ArcCatalog рекомендовал, если, конечно, данные не монстровые (загрузка из cmd идет чуть быстрее и commit interval можно уменьшить).
>>нужно ли давать "загрузчику" (или "создателю" структур данных), какие-либо привилегии на объекты схемы sde, хотя бы привилегию references на какие-либо таблицы sde?
Если загрузка идет нормально, без ругани, то и не стоит. При установке данных для курсов по введению в ArcSDE юзерам даются следующие привелегии:
CREATE SESSION
ALTER SESSION
CREATE CLUSTER
CREATE DATABASE LINK
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE SYNONYM
CREATE TABLE
CREATE TYPE
CREATE TRIGGER
CREATE VIEW
И еще Unlimited квота на TEMP и табличное пространство, где лежат их данные. Про табл. пр-во SDE - ни слова.
Привелегии явно завышены. Обычно сам ставлю resource (connect и так есть, когда юзера из интерфейса лепишь) и , а также квоты на TEMP и табличное пространство, где лежат данные. Привелегии на таб.пр. SDE приходилось давать только на MS SQL Server (да и нехилые привелегии - db owner). В доке нигде не видел указаний на то, чтобы права на таб.пр. SDE были необходимы.

Цитаты взяты с www.esri.com там support по ArcSDE, knowlage base, далее набрал поиск по "sde user".

Тут - вопрос (3):
Как по-правильному делать backup & restore не знаю. Процедуры тут ничем не отличаются от стандартных ораклевых, но все равно - не знаю как конкретно.
Но поделюсь опытом - пробовал восстановить БД по дампу - ничего нормального не получилось, только разрозненные таблицы.
Если ДАННЫЕ меняются надо восстанавливать ВСЕ, ведь таблички A и D (если данные правятся из ArcMap) хранятся в пользовательских т.п., а не в SDE.

Призыв: Если кто знает как делать backup & restore напишите по шагам!!!

>>>(4): они очень важны - метаданные?
Если задается такой вопрос - то не нужны, поскольку вы еще не уткнулись в проблему разгребания завалов, когда вопрос ставится по-другому - где прописать описательную инфу по каждому классу и как найти нужные данные по этой информации (для чего эти метаданные и придуманы).

>>>(5) Про таблицы sde_logfile и sde_logfile_data - можно кратко - что там?
Таблица  SDE_LOGFILES содержит метаданные журнала регистрации (log file). Хранимые значения включают название журнала регистрации и его идентификатор, идентификатор регистрации, флаги и информацию, касающуюся сеанса.  
SDE_LOGFILES
Название            Тип данных        Могут ли отсутствовать данные столбца?
logfile_name            SE_STRING_TYPE(256)    NOT NULL
(название файла)       
logfile_id            SE_INTEGER_TYPE        NOT NULL
(идентификатор файла)
logfile_data_id            SE_INTEGER_TYPE        NOT NULL
(идентификатор файла данных)
registration_id            SE_INTEGER_TYPE        NOT NULL
(идентификатор регистрации)
flags                SE_INTEGER_TYPE        NOT NULL
(флаги)   
session_tag            SE_INTEGER_TYPE        NOT NULL
(тэг сеанса)

Таблица SDE_LOGFILE_DATA содержит список записей бизнес таблицы, которые являются частью каждого файла регистрации.
 
SDE_LOGFILE_DATA
Название            Тип данных        Могут ли отсутствовать данные столбца?
logfile_data_id            SE_INTEGER_TYPE        NOT NULL
(идентификатор данных файла регистрации)
sde_row_id            SE_INTEGER_TYPE        NOT NULL
(идентификатор строки sde)
(Цитата из книги "Managing ArcSDE", через пару месяцев выйдет на русском). Разобраться что к чему сложно, а следовательно и хранить не к чему, если вас не особо заботит, кто из юзеров что делал. Конечно эту информацию вытягивать из этих таблиз сложно, но можно. Как мне говорили знающие люды, для нормального отслеживания деятельности юзеров пишутся триггеры и по ним заносится инфа в отдельные таблички. Как что конкретно - не спрашивайте - не знаю, а кто говорил - не помню, пытайте ораклистов.
0 голосов
ответил 12 Май, 03 от igorstr (6,660 баллов)
Решил продублировать решение из 8-ного форума.
1. Когда идет работа из командной строки ПЕРЕКОДИРОВКА данных идет в соответствии с установками переменной окружения NLS_LANG, то есть если ее установить равной RUSSIAN_CIS.RU8PC866 (хоть в том же командном окне), то ДАННЫЕ будут перекодироваться в (sde2shp) 866 кодировку. В этом случае и Excel, ArcView3, ArcGIS будут видеть нормальную кирилицу, поскольку в ЗАГОЛОВКЕ прописано, что кодовая сраница файла (берется кодовая сраница командной строки, OEMCP в реестре) равна 866. Никакими установками переменных заставить прописывать в заколовке другую информацию не удалось.
2 Поменять информацию в заголовке удалось только изменением информации в реестре в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage OEMCP=1251 с перезагрузкой компьютера. После этой операции в заголовке начинает прописываться виндовая кодировка (опять же она НЕ будет зависеть от NLS_LANG и, соответственно, от реальной перекодировки данных).
Добро пожаловать на сайт Вопросов и Ответов, где вы можете задавать вопросы по GIS тематике и получать ответы от других членов сообщества.
...