Oracle mysq
Oracle
Здесь я записываю проблемы которые возникли при понимании Oracle
Просмотр параметров и переменных
Параметры
SHOW PARAMETERS
например
SQL> SHOW PARAMETERS DB_CREATE; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_create_file_dest string db_create_online_log_dest_1 string db_create_online_log_dest_2 string db_create_online_log_dest_3 string db_create_online_log_dest_4 string db_create_online_log_dest_5 string
Пулы памяти
SQL> SELECT * from v$sgastat; ... POOL NAME BYTES ------------ -------------------------- ---------- shared pool KTI latches 576 shared pool KKJ WRK LAT 480 shared pool kfkhsh_kfdsg 4104 shared pool event statistics ptr arra 1360 shared pool KGKP randnum 40000 large pool PX msg pool 903840 large pool free memory 3290464 java pool free memory 4194304 602 rows selected.
SHOW TABLES
SELECT * FROM USER_TABLES;
CREATE DATABASE
В Oracle понятие DATABASE отличается от MySQL.
С точки зрения Oracle, "База данных" - это отдельный экземпляр, т.е. в терминах MySQL это фактически отдельная (или почти отдельная инсталляция). Потому, создание базы данных в случае Oraclre - достаточно трудоемкий (и не очевидный) процесс.
Tablespace
Tablespace - это контейнер для данных (таблиц и индексов но НЕ триггеров) и по сути - файл на диске.
ALTER SYSTEM SET DB_CREATE_FILE_DEST = '$ORACLE_HOME/tablespace/ts_test';
CREATE TABLESPACE TS_sirmax DATAFILE '$ORACLE_HOME/tablespace/ts_test/sirmax.dat' SIZE 100M REUSE AUTOEXTEND ON NEXT 2M MAXSIZE 200M
SQL> SELECT tablespace_name, file_name, status, bytes FROM dba_data_files WHERE tablespace_name LIKE 'TS_SIRMAX%'; TABLESPACE_NAME FILE_NAME STATUS BYTES ------------------------------ -------------------------------------------------------------------------------- --------- ---------- TS_SIRMAX /export/home/oracle/10g/tablespace/ts_test/sirmax.dat AVAILABLE 104857600
- http://www.firststeps.ru/sql/oracle/r.php?122
- http://download.oracle.com/docs/cd/B13789_01/server.101/b10759/statements_7003.htm
Пользователь или схема
(оригинал взят: <ccылка утеряна, кто знает - подскажите>
В Oracle понятия "схема" и "пользователь" нераздельно слились воедино. Формально два разных слова "user" и "schema" используются в Oracle для обозначения одного и того же: "схемы-пользователя". Документация на этот счет стыдливо говорит, что "при заведении пользователя с помощью предложения CREATE USER автоматически создается схема с таким же именем".
С другой стороны, отдельных манипуляций со схемами в Oracle не предусмотрено.
Команда CREATE SCHEMA в Oracle обманчива; она не создает схему, как можно было бы подумать
Для разработчика же эти два понятия не идентичны. Так, схема представляет собой своего рода контейнер хранимых в БД объектов, несущий традиционно двойную функциональную нагрузку: как средства организации данных (объектов в базе много, но не всем приложениям все они интересны) и как средство защиты данных от посторонних приложений. Пользователь же, по своей изначальной идее - это конкретное лицо, которое может подключаться к СУБД для работы с теми или иными данными, проверяться на наличие полномочий, контролироваться на предмет совершаемых действий и т. д.
Данные принадлежат информационной системе, предприятию, а пользователи могут наниматься и увольняться. Как сымитировать такой способ работы в Oracle?
Решение
Возможно, кто-то уже придумал свое решение этой проблемы. Если нет - можно воспользоваться предлагаемым ниже.
Для хранения объектов "отдела кадров" создаем схему (-пользователя) HR:
CREATE USER hr IDENTIFIED BY hr;
Далее по мере необходимого уточняем все свойства этой схемы, например:
ALTER USER hr DEFAULT TABLESPACE hr_ts DEFAULT TABLESPACE temp; и так далее.
Для физических лиц создаем пользователей Oracle, например:
CREATE USER pete IDENTIFIED BY thisismepete; CREATE USER mary IDENTIFIED BY maryiam;
Далее пользователям нужно приписать необходимые свойства. В типичном случае все они одинаковы, так что имеет смысл написать один-единственный сценарий, который наделял бы каждого нового "Петю" или "Машу" требуемыми полномочиями. Что туда должно входить ? Как минимум, системная привилегия CREATE SESSION. Но кроме этого, для доступа к своим таблицам от имени HR следует выдать что-то вроде
GRANT SELECT, INSERT, UPDATE, DELETE ON main_hr_table TO pete;
Это еще не все. Пользователь PETE действительно теперь сможет подключаться к СУБД от своего имени и работать с таблицей MAIN_HR_TABLE, однако ссылаться на нее он будет вынужден по полному имени: HR.MAIN_HR_TABLE, так как это не его таблица. Можно ли избежать этого и заставить его чувствовать себя "как дома"? Можно. Ему достаточно выдать:
ALTER SESSION SET CURRENT_SCHEMA=hr;
Удобнее, однако, эту команду "завернуть" в триггер, срабатывающий при подключении к "схеме" PETE, то есть выдать, например, от имени SYS:
CREATE OR REPLACE TRIGGER set_hr_schema_for_pete AFTER LOGON ON pete.SCHEMA BEGIN EXECUTE IMMEDIATE 'ALTER SESSION SET CURRENT_SCHEMA=hr'; END; /
Теперь, подключаясь к СУБД, пользователь PETE будет видеть объекты HR "как свои", по короткому имени, правда свои собственные таблицы он вынужден будет называть "целиком", например PETE.MY_PETE_TABLE, но нам, кажется, это и не важно.
Особенности предложенного решения
- его надо автоматизировать
- невозможно создавать и удалять объекты
- можно использовать системный аудит
Альтернатива Предложена в Oracle 9.0: "корпоративные пользователи" и сервер имен.
