Показаны сообщения с ярлыком oracle. Показать все сообщения
Показаны сообщения с ярлыком oracle. Показать все сообщения

понедельник, 1 июля 2013 г.

Удаление LUN SAN-диска на Oracle Linux без перезагрузки операционной системы

перепост: http://linuxpkd.blogspot.ru/2012/03/san-disk-is-removed-from-multipath.html


  1. Удостовериться, что диск не используется:
    размонтировать, удалить из fstab
    удалить из lvm
  2. Удалить диск, используя одно из следующих действий:
    1. #multipath –f /dev/mpath/mpath1
    2. 
    # multipathd –k
    multipathd> show multipaths
    multipathd> remove multipath mpath0
    3. #dmsetup remove $device-name
    4. можно прописать диск в блэклистах multipath, чтобы при следующей загрузки он не использовался:
    # /sbin/scsi_id -g -u -s /block/sdaj
    blacklist { wwid 360000970000192604349533030344232 }
  3. Удалить диск из системы:
    # echo "1" > /sys/block/sdX/device/delete


четверг, 23 мая 2013 г.

Включение/выключение режима архивных логов в Oracle DB

перепост http://vistababa.wordpress.com/2008/06/12/how-to-turn-archivelog-mode-on-and-off-in-oracle/

Включение режима архивных логов
Вначале убедимся, что БД не в режима архивных логов

SQL> select log_mode from v$database;
LOG_MODE
————
NOARCHIVELOG

или
SQL> archive log list;
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /archivelog
Oldest online log sequence 7193
Current log sequence 7194
SQL>

Переводим в режим архивных логов:
SQL> shutdown immediate;
SQL> startup mount exclusive;
SQL> alter database archivelog;
SQL> alter database open;

Проверяем:
SQL> select log_mode from v$database;
LOG_MODE
———-
ARCHIVELOG
SQL>

Убеждаемся:
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /archivelog
Oldest online log sequence 7194
Next log sequence to archive 7195
Current log sequence 7195
 
Чтобы работало после перезагрузки запишем в файл параметров: 
SQ> alter system set log_archive_start=TRUE scope=spfile;
и перезагрузим БД
(параметр LOG_ARCHIVE_START является устаревшим с 10.1. Автоматическое архивирование достигается переводом базы в ARCHIVELOG состояние (http://docs.oracle.com/cd/E18283_01/server.112/e17222/changes.htm)

Note1: Необходимо сразу снять резервную копию.
Note2: Желательно установить параметры init.ora: log_archive_dest, log_archive_dest_1, log_archive_format

Выключение режима архивных логов  
Убеждаемся, что БД в режиме архивных логов:
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /archivelog
Oldest online log sequence 7194
Next log sequence to archive 7195
Current log sequence 7195
SQL>
Выключаем:
SQL> startup mount excluseve;
SQL> alter database noarchivelog;
SQL> alter database open;
Проверяем:
SQL> archive log list;
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /archivelog
Oldest online log sequence 7194
Current log sequence 7195
SQL>
Note1: Все предыдущие копии архивных логов идут в /dev/null.

понедельник, 29 апреля 2013 г.

Ensure CELL_OFFLOAD_PROCESSING is FALSE in Non-Exadata

перепост http://cgswong.blogspot.ru/2011_06_01_archive.html


Ensure CELL_OFFLOAD_PROCESSING is FALSE in Non-Exadata

A colleague of mine recently brought to my attention a curious wait event that they were experiencing for 'ASM file metadata operation' which occurs when doing operations such as a DROP TABLESPACE, or in this case when using Data Pump. Though the server was basically not doing anything the CPU usage was 100% and there was the strange wait event on 'ASM file metadata operation' with high waits on 'ksv master wait'. So to Oracle Support they went via opening an SR.

It seems that upon applying a PSU to 11.2.0.2 (as of this writing PSU 2 is that latest so likely this will not occur in PSU 3 but that is only my guess) the parameter cell_offload_processing is set to TRUE. In an Exadata environment this is the appropriate setting, however, in a non-Exadata environment, which it was in this case, this causes performance issues to arise as processes on the RDBMS side await on a reply from the ASM side which is trying to delivery smart-scan results.

The quick fix is of course to simply reset the parameter to FALSE, i.e. 'ALTER SYSTEM SET cell_offload_processing = FALSE scope=both'. If you prefer you can instead apply patch 11800170. Per the MOS note, "High 'ksv master wait' And 'ASM File Metadata Operation' Waits In Non-Exadata 11g [ID 1308282.1]" this issue is fixed in 11.2.0.2 PSU 3, 11.2.0.3 and 12.1.

пятница, 22 марта 2013 г.

Отсылка почты из Oracle 11g R2 с помощью utl_mail и utl_smtp


repost http://blogdaprima.com/2012/install-configure-utl_mail-and-utl_smtp-on-oracle-11g-r2/

Install / Configure utl_mail and utl_smtp on Oracle 11g R2

Установим необходимые пакеты и раздадим гранты:
[host@oracle]$ cd $ORACLE_HOME/rdbms/admin
[host@oracle]$sqlplus / as sysdba
SQL> @utlmail
SQL> @utlsmtp
SQL> @prvtmail.plb
SQL> GRANT EXECUTE ON utl_mail TO PUBLIC;
SQL> GRANT EXECUTE ON utl_smtp TO PUBLIC;
SQL> alter system set smtp_out_server='dmits10' scope=both;


Раздадим соответствующие привилегии (тут RMS13DEV - пользователь БД, который будет отсылать почту, DMITS10 - доменное имя smtp-сервера):

begin
  dbms_network_acl_admin.create_acl (
    acl => 'utl_mail.xml',
    description => 'Allow mail to be send',
    principal => 'RMS13DEV',
    is_grant => TRUE,
    privilege => 'connect'
  );
  commit;
end;

/

begin
  dbms_network_acl_admin.add_privilege (
    acl => 'utl_mail.xml',
    principal => 'RMS13DEV',
    is_grant => TRUE,
    privilege => 'resolve'
  );
  commit;
end;
/


begin
  dbms_network_acl_admin.assign_acl(
    acl => 'utl_mail.xml',
    host => 'dmits10'
  );
  commit;
end;

/

понедельник, 22 октября 2012 г.

Работа нескольких oracle instance на одной машине под одним пользователем OS

  1. Ставим голую БД, без схем примеров.
  2. С помощью dbca создаём необходимое количество баз данных (в моём случае - billing, bilarc).
  3. Далее необходимо научить listener работать с обеими базами. Пример listener.ora:

    LISTENER =
    (DESCRIPTION_LIST =
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
    )
    )

    ADR_BASE_LISTENER = /home/oracle/app/oracle

    SID_LIST_LISTENER =
    (SID_LIST =
    (SID_DESC =
    (SID_NAME = billing)
    (ORACLE_HOME = /home/oracle/app/oracle/product/11.2.0/dbhome_1)
    )
    (SID_DESC =
    (SID_NAME = bilarc)
    (ORACLE_HOME = /home/oracle/app/oracle/product/11.2.0/dbhome_1)
    )
    )
  4. Базы данных запускаются последовательно:
    sqlplus /nolog
    SQL> connect sys@billing as sysdba
    SQL> startup
    ...
    SQL> connect sys@bilarc as sysdba
    SQL> startup


четверг, 24 мая 2012 г.

Установка Oracle® Database Gateway 11g Release 2 (11.2) для MSSQL на Linux x86-64

Используем документацию http://docs.oracle.com/cd/E11882_01/...e12013/toc.htm
Версии:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
MSSQL 2000
[oracle@oebs admin]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
[oracle@oebs admin]$ cat /etc/oracle-release
Oracle Linux Server release 5.5

  1. Для указанной версии Oracle БД ставим софт из p10098816_112020_Linux-x86-64_5of7.zip стандартным образом, через runInstaller. Выбираем среди предлагаемых продуктов MSSQL. Установка должна завершится без ошибок.
  2. Прописываем в $ORACLE_HOME/dg4msql/admin/initdg4msql.ora (тут прописываются данные удалённого mssql-сервера):
    HS_FDS_CONNECT_INFO=[<доменное имя или адрес севера mssql>]:<порт сервера mssql>//<база данных mssql>
    HS_FDS_TRACE_LEVEL=OFF
    HS_FDS_RECOVERY_ACCOUNT=RECOVER
    HS_FDS_RECOVERY_PWD=RECOVER
  3. Прописываем дополнительный лисенер в $ORACLE_HOME/network/admin/listener.ora (тут прописываются данные локального лисенера. <название лисенера> должно совпадать с названием того лисенера, который уже есть!!!):
    SID_LIST_<название листенера>=
        (SID_LIST=
            (SID_DESC=
                (SID_NAME=dg4msql)
                (ORACLE_HOME=/home/oracle/product/db11202)
                (PROGRAM=dg4msql)
            )
        )
  4. Прописываем новый инстанс в $ORACLE_HOME/network/admin/tnsnames.ora (тут прописываются данные, где инсталлирован агент - в нашем случае - сам хост, где установлена база данных ORACLE):
    dg4msql =
        (DESCRIPTION =
            (ADDRESS =
                (PROTOCOL = TCP)
                (HOST = <доменное имя хоста, где установлен агент. В нашем случае - текущий локальный хост с базой>)
                (PORT = <порт, по которому слушает лисенер. Должен совпадать с портом, указанным в listener.ora>)
            )
        (CONNECT_DATA =
            (SID = dg4msql)
        )
        (HS=OK)
        )
  5. В $ORACLE_HOME/network/admin/sqlnet.ora должно быть написано
    NAMES.DIRECTORY_PATH= (TNSNAMES)
  6. Рестуртуем listener:
    lsnrctl stop <название лисенера>
    lsnrctl start <название лисенера>
    lsnrctl status <название лисенера>
    В информации о статусе должно присутствовать:
    Service "dg4msql" has 1 instance(s).
      Instance "dg4msql", status UNKNOWN, has 1 handler(s) for this service...
    The command completed successfully
  7. Создаём dblink:
    sqlplus "/as sysdba":
    SQL> create public database link mssql connect to "<имя пользователя mssql>" IDENTIFIED BY "<пароль пользователя mssql>" USING 'dg4msql';
    пример:
  8. Удаление dblinkа при необходимости делается следующей командой:
    SQL> drop public database link mssql;
  9. Селекты делаются следующей командой:
    SQL> select * from user.table@mssql
  10. Синтаксис для использования алиасов своеобразный:
    SQL> select "t"."column_name" from "user"."table"@mssql "t";
  11. При работе с полями mssql типа datetime выдаёт то правильные значения, то бинарный мусор. Помогает явное приведение типа:
    SQL> select to_date("t"."column_with_date") from "user"."table"@mssql "t";

четверг, 9 июля 2009 г.

Битовые индексы соединения Oracle DB (bitmap join indexes, BJI)

(http://www.interface.ru/fset.asp?Url=/oracle/or9inewvozmojnosti.htm)
Невозможно оставить без внимания ещё одно оригинальное новшество – битовые индексы соединения (bitmap join indexes, BJI). Это обычные битовые индексы, но построенные по столбцам, которых в индексируемой таблице нет. Например, в таблице продаж (назовем её по традиции Sales) есть код региона продажи, но нет его названия. Название есть в справочнике регионов (Regions). В то же время запрос, выбирающий все продажи по региону с заданным названием, довольно типичен. При его выполнении каждый раз требуется соединение (join) таблиц Sales и Regions. Рассмотрим пример.
Создадим таблицы:
create table Regions
(
region_id number primary key,   -- первичный ключ обязателен для создания BJI
region_name varchar2(200)
);
create table Sales
(
id number primary key,
region_id number,               -- опустим ограничения внешнего ключа
product_id number,
amount number,
sal_date date
);
Выполним запрос:
Select sum(amount)
from sales, regions
where
     regions.region_id = sales.region_id
 and regions.region_name = 'Центр'
Рассмотрим план выполнения этого запроса (это не единственно возможный, но вполне вероятный план). В плане, естественно, присутствует просмотр обеих таблиц и операция их соединения:
SELECT STATEMENT Optimizer=ALL_ROWS
SORT (AGGREGATE)
NESTED LOOPS
  TABLE ACCESS (FULL) OF 'SALES'
  TABLE ACCESS (BY INDEX ROWID) OF 'REGIONS'
    INDEX (UNIQUE SCAN) OF 'REGIONS_PK' (UNIQUE)
Если же это соединение выполнить один раз при построении индекса, и в индексе хранить указатели на строки таблицы Sales вместе с соответствующими названиями регионов из таблицы Regions, то для выполнения вышеописанного запроса таблица Regions вообще не понадобится, и можно избежать очень дорогостоящей операции соединения.
Создадим индекс:
create bitmap index Sales_reg_bji
on Sales(regions.region_name)
from Sales, Regions
where sales.region_id=regions.region_id
Чтобы побудить оптимизатор использовать этот индекс, применим подсказку (hint). В реальности, если таблицы будут достаточно большими, подсказки скорее всего не понадобятся, т.к. стоимость выполнения этого запроса с использованием индекса будет существенно меньше, чем без него:
select /*+ index(sales sales_reg_bji) */
 sum(amount) from sales, regions
 where
       regions.region_id   = sales.region_id
   and regions.region_name = 'Центр'
Рассмотрим план выполнения и убедимся, что просмотр таблицы Regions и операция соединения исчезли:
SELECT STATEMENT Optimizer=ALL_ROWS
SORT (AGGREGATE)
  TABLE ACCESS (BY INDEX ROWID) OF 'SALES'
    BITMAP CONVERSION (TO ROWIDS)
      BITMAP INDEX (SINGLE VALUE) OF 'SALES_REG_BJI'
Средства обеспечения масштабируемости приложений технологию разработки напрямую не затрагивают, но позволяют обойтись без модификации приложения при увеличении объёма данных или количества пользователей.

Каркасные планы выполнения и их применение в практике

на тестовом сервере:

SQL> connect system as sysdba
SQL> @e:\oracle\ora92\rdbms\admin\dbmsol.sql

SQL> grant create any outline to LOGIN;
SQL> grant execute on dbms_outln to LOGIN;
SQL> grant execute on dbms_outln_edit to LOGIN;
SQL> ALTER SYSTEM SET CREATE_STORED_OUTLINES = TRUE;

далее параллельно запускаем проблеммное приложение, заставляем его делать проблеммные запросы
после этого:

SQL> ALTER SYSTEM SET CREATE_STORED_OUTLINES = FALSE

проконтроллировать полученные каркасные планы и хинты можно так:
select * from user_outlines;
select * from user_outline_hints;
название конкретно нужного плана можно посмотреть по user_outlines.sql_text

далее необходимо править хинты у полученных каркасных планов:
подготовка:
SQL> connect LOGIN
SQL> execute dbms_outln_edit.create_edit_tables;

копирование в приватный каркасный план (править можно только его):
SQL> create private outline priv_outln1 from SYS_OUTLINE_081007125758140;
SQL> column hint# format 999999
SQL> column hint_text format a28
SQL> column user_table_name format a16
SQL> set pages 1000
SQL> select hint#, hint_text, user_table_name from ol$hints where ol_name = 'PRIV_OUTLN1';

HINT# HINT_TEXT USER_TABLE_NAME
------- ---------------------------- ----------------
1 NOREWRITE
2 RULE
3 NOREWRITE
4 NO_EXPAND
5 USE_NL(LR)
6 USE_NL(CT)
7 USE_NL(LZ)
8 USE_NL(CN
9 ORDERED
10 NO_FACT(LR)
11 NO_FACT(CT)
12 NO_FACT(LZ)
13 NO_FACT(CN
14 NO_FACT(CX)
15 AND_EQUAL(CX M2_CTSXR_LTTLZ_FRGN M2_CTSRX_LTTPN_FRGN)
16 INDEX(CN M2_CITNM_PK)
17 INDEX(LZ M2_LTZON_PK)
18 INDEX(CT M2_CTS_PK)
19 INDEX(LR M2_LTMTSRG_PK)

SQL> update ol$hints set hint_text='USE_HASH(LR)' where hint# = 5;
SQL> update ol$hints set hint_text='USE_HASH(CT)' where hint# = 6;
SQL> update ol$hints set hint_text='USE_HASH(LZ)' where hint# = 7;
SQL> update ol$hints set hint_text='USE_HASH(CN)' where hint# = 8;
SQL> select hint#, hint_text, user_table_name from ol$hints where ol_name = 'PRIV_OUTLN1';

HINT# HINT_TEXT USER_TABLE_NAME
------- ---------------------------- ----------------
1 NOREWRITE
2 RULE
3 NOREWRITE
4 NO_EXPAND
5 USE_HASH(LR)
6 USE_HASH(CT)
7 USE_HASH(LZ)
8 USE_HASH(CN)
9 ORDERED
10 NO_FACT(LR)
11 NO_FACT(CT)
12 NO_FACT(LZ)
13 NO_FACT(CN)
14 NO_FACT(CX)
15 AND_EQUAL(CX M2_CTSXR_LTTLZ_FRGN M2_CTSRX_LTTPN_FRGN)
16 INDEX(CN M2_CITNM_PK)
17 INDEX(LZ M2_LTZON_PK)
18 INDEX(CT M2_CTS_PK)
19 INDEX(LR M2_LTMTSRG_PK)

SQL> commit;
SQL> execute dbms_outln_edit.refresh_private_outline('PRIV_OUTLN1');

копируем приватный обратно в общий:
SQL> create or replace outline SYS_OUTLINE_081007125758140 from private priv_outln1;

переименовываем и перекидываем в другую группу (для переноса на ПРОД):
SQL> alter outline SYS_OUTLINE_081007125758140 rename to taraandr001;
SQL> alter outline taraandr001 change category to TARAANDR;

и очистим дефолтную группу, дабы не мешалось:
SQL> exec outln_pkg.drop_by_cat('DEFAULT');

проконтроллируем, что остались только нужные:
select * from user_outlines;

далее переносим с ТЕСТа:
exp system/ file=myoutln.dmp tables=(outln.ol$,outln.ol$hints,outln.ol$nodes) statistics=none
на ПРОД:
imp system/ file=myoutln.dmp full=y ignore=y

и далее на ПРОДе включаем использование:
SQL> alter system set use_stored_outlines = TARAANDR;

используются до следующего рестарта базы.
для постояшного включения при перезагрузке (используется категория DEFAULT):
create or replace trigger enable_outlines_trig
after startup on database
begin
execute immediate('alter system set use_stored_outlines=true');
end;

67536.1 Stored Outline Quick Reference
144194.1 Editing Stored Outlines in Oracle9i - an example
728647.1 How to Transfer Stored Outlines from One Database to Another (9i and above)
560331.1 How to Enable USE_STORED_OUTLINES Permanently

дополнительно:
132547.1 Using Stored Outlines

четверг, 16 августа 2007 г.

Установка Oracle 9i на HP-UX 11v3 (11.31) на Itanium

Намедни пришел к нам тестовый сервер HP rx7620, дле тестирования возможности переноса базы с rp7440 (PA-RISC).
Процесс установки Oracle 9i на данную машину не очень тривиален.
Прежде всего необходимо поставить патчи на операционную систему. Патчи такие - PHKL_35936 и PHKL_36054. Они зависят друг от друга, поэтому необходимо их объединить в один depot скриптом create_depot_hp-ux_11 и ставить одновременно.
Далее необходимо поставить последнюю java 1.3. Скачать её можно отсюда: http://www.hp.com/products1/unix/java. После установки необходимо поправить в конфиге инсталлятора Oracle /Disk1/install/hpunix/oraparam.ini параметр JRE_LOCATION на /opt/java1.3/jre
Подробно это описано в ноте 400227.1.
Саму процедуру инсталляции БД необходимо запускать с ключиком "-ignoreSysPrereqs":
$ /oracle/Disk1/runInstaller
-ignoreSysPrereqs

Когда инсталлятор страшивает, в какой кодировке создавать базу пишем CL8ISO8859P5.

Дополнительный материал:
Metalink 400227.1
http://www.decus.de/sig/dbi/oracle/hp_oracle_ctc_newsletter_200705.html

Ярлыки