Скрипты для перекомпиляции INVALID-объектов

После некоторых действий в базе (импорта, обновления, установки CPU и др.) часто обнаруживаются INVALID-объекты, которые рекомендуется лечить запуском скрипта $ORACLE_HOME\rdbms\admin\utlrp.sql.
Сейчас для компиляции инвалидных функций и процедур я пользуюсь sqlplus-скриптом с сайта Don'а Burleson'а invalid_func_proc.sql.
А для компиляции инвалидных пакетов и тел пакетов скриптом с Oracle-Base invalid_pkg.sql.

--invalid_func_proc.sql
set heading off;
set feedback off;
set echo off;
set lines 999;
set page 500;
spool run_invalid.sql
select
'ALTER ' || OBJECT_TYPE || ' ' ||
OWNER || '.' || OBJECT_NAME || ' COMPILE;'
from dba_objects
where status = 'INVALID'
and object_type in ('FUNCTION','PROCEDURE');
spool off;
set heading on;
set feedback on;
set echo on;
--@run_invalid.sql
--===========================
--invalid_pkg.sql.
SET SERVEROUTPUT ON SIZE 1000000
BEGIN
FOR cur_rec IN (SELECT owner,
object_name,
object_type,
DECODE(object_type, 'PACKAGE', 1,
'PACKAGE BODY', 2, 2) AS recompile_order
FROM dba_objects
WHERE object_type IN ('PACKAGE', 'PACKAGE BODY')
AND status != 'VALID'
ORDER BY 4)
LOOP
BEGIN
IF cur_rec.object_type = 'PACKAGE' THEN
EXECUTE IMMEDIATE 'ALTER ' || cur_rec.object_type ||
' "' || cur_rec.owner || '"."' || cur_rec.object_name || '" COMPILE';
ElSE
EXECUTE IMMEDIATE 'ALTER PACKAGE "' || cur_rec.owner ||
'"."' || cur_rec.object_name || '" COMPILE BODY';
END IF;
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.put_line(cur_rec.object_type || ' : ' || cur_rec.owner ||
' : ' || cur_rec.object_name);
END;
END LOOP;
END;
/

Протестить mount over ssh?

Нашел про монтирование удаленной фс через ssh - надо протестить ...
http://www.cyberciti.biz/tips/rhel-centos-mounting-remote-filesystem-using-sshfs.html
да и вообще похоже много чего полезного здесь

su - oracle - Your default context is user_u:system_r:unconfined_t.

После перезагрузки сервака после вчерашнего обновления openssh (еще не определил как это связано с сабжем), не сработал dbora - "пошел" разбираться. При попытке изменить контекст юзера получил
[root@mysrv]# su - oracle
Your default context is user_u:system_r:unconfined_t.

Do you want to choose a different one? [n]
[oracle@mysrv ~]$
Теперь ясно почему не сработал dbora.

Гугл посоветовал закомментарить в /etc/pam.d/su строку с pam_selinux.so open multiple

#session required /lib/security/$ISA/pam_selinux.so open multiple
session required /lib/security/$ISA/pam_selinux.so open

и это помогло.

How to enable telnet in CentOS

На время обновления openssh на всякий случай приподнял telnet по howto с centos.org

1. Login to your server through SSH and su to root.
2. Type pico /etc/xinetd.d/telnet
3. Look for the line: disable = no and replace with disable = yes
4. Now restart the inetd service: /etc/rc.d/init.d/xinetd restart
5. Turn off it through chkconfig as well because it can still start through that.
/sbin/chkconfig telnet off

SQL> drop database;

Минут 10 убил чтобы перевести базу в нужное состояние перед drop'ом :)
SQL> startup mount EXCLUSIVE restrict force;
ORACLE instance started.

Total System Global Area 536870912 bytes
Fixed Size 1261860 bytes
Variable Size 167775964 bytes
Database Buffers 364904448 bytes
Redo Buffers 2928640 bytes
Database mounted.
SQL> drop database;

Обновление пакетов Linux на примере обновления open-ssh до 4.6p1 на CentOS 4.4

1) Обновление из RPM-исходника (пример с zlib)
# wget ftp://chuck.ucs.indiana.edu/pub/array2/linux/fedora/linux/core/5/source/SRPMS/zlib-1.2.3-1.2.1.src.rpm
# rpmbuild --rebuild zlib-1.2.3-1.2.1.src.rpm
# rpm -Uhv /usr/src/redhat/RPMS/i386/zlib-*1.2.3-1.2.1.i386.rpm

2) Обновление из тарбола (на примере openssh)
# cd /usr/src/redhat/SOURCES
# wget ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-4.6p1.tar.gz
# tar zxvf openssh-4.6p1.tar.gz
Ищем файлик типа spec
# find . -type f -name *.spec
# cd openssh-4.6p1/contrib/redhat/
# vi openssh.spec
%define no_x11_askpass 1
%define no_gnome_askpass 1
# rpmbuild -bb --clean --target i586 openssh.spec
# cd /usr/src/redhat/RPMS/i586
# rpm -Uvh openssh-*4.6p1-1.i586.rpm
Во время установки ругнулось на зависимости старых пакетов
error: Failed dependencies:
openssh = 3.9p1-8.RHEL4.9 is needed by (installed) openssh-askpass-3.9p1-8.RHEL4.9.i386
openssh = 3.9p1-8.RHEL4.9 is needed by (installed) openssh-askpass-gnome-3.9p1-8.RHEL4.9.i386
- удалил их через
# rpm -e <пакеты, на которые ругалось>

После удаления повторил установку и перегрузил процесс sshd через
kill -1

3) Установка или обновление при помощи yum
#yum install XFree86-devel
#yum install gtk2-devel
#yum update openssl

mount NFS from HP-UX onto Oracle on Linux

Для того, чтобы сделать импорт дампа базы из hp-ux на linux проделал следующее
1) на hp-ux под root'ом
- в /etc/rc.config.d/nfsconf значения параметров NFS_SERVER и START_MOUNTD заменил на 1.
- запустил /sbin/init.d/nfs.server start
- дамп файл лежит в /dmp, поэтому в /etc/exports добавил строчку
/dmp -anon=65534,async
- перечитал изменения /usr/sbin/exportfs -a
- проверил /usr/sbin/exportfs
2) на Linux под root'ом
также решил смонтировать и дал команду
$ mount name_of_server:/dmp /dmp -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
Когда я ее дал в начале без опций $ mount name_of_server:/dmp /dmp, то при попытке сделать импорт из этой директории вывалилась ошибка:
ORA-27054: NFS file system where the file is created or resides is not mounted with correct options

RMAN-03002: failure of Duplicate Db command at

Технари бросили задачку сделать им копию продакшн-базы для тестирования новой версии их софта. Датафайлы базы в объеме чуть более 160 Гб. Первая мысль, которая пришла - поднять вторую базу на этом же сервере через RMAN duplicate. Но .... sga рабочей базы забила всю доступную оперативную память сервера, а там ее всего 2Gb и есна уменьшать ее нельзя :(
Тогда как сделать копию базы, если нет железа, где ее развернуть? Спросить у офисников VMWare-машинку. Удалось найти у них VMWare-машинку на 2Gb RAM, но дискового пространства всего лишь 170 Гб :( - больше нету. Ок, пока я поднял на ней Centos 4.4 и Oracle 10gR2.
Итак остаются две проблемы - для дамп-файла нет места на сервере. Также его нет на VMWare-сервере, который выделен под копию базы. Cетевой экспорт посредством network_link не подходит, т.к. в базе огромная куча таблиц с полями типа LONG (Интересно убрано ли это ограничение в недавно выложенной 11g?).
Доовольный и потирая руки, т.к. никогда не делал его, я ответил себе - нужно попробовать RMAN duplicate!!! Проведя тесты у себя на тестовой базе, подготовил duplicate.rcv c содержимым:
run {
allocate auxiliary channel 'aux_sbt' type 'sbt_tape';
duplicate target database to 'SID новой базы'
skip tablespace 'ненужный TS';
}
exit;
Запустил команду
$ rman target / auxiliary sys/passwd@ @duplicate.rcv
и .... получил ошибки, основной смысл которых RMAN-03002: failure of Duplicate Db command at .... Погуглив и пошаривши по металинку осеняет!!! кого я гоню-то - и грустно и смешно :( ОСи то разные :( Тесты я провел на Linux-ах и с той и с этой стороны, а под продакшн базой у меня сервачок HP rp5470 с HP-UX 11.11, когда как для тестовой копии я поднял Linux - другого варианта не было. Известно, что при RMAN restore (который является частью duplicate) возможны только одинаковые ОСи. Вот он пример того, как что-то зная в теории, выпускаешь из виду на практике, пока не "наступишь"... Эээхх....

А с копией базы на самом деле оказалось не все потеряно. Эту боевую базу поднимал я и располагал данные на MSA1000. Тоже неплохой опыт был. Т.к. вот к моему серваку был подключен еще один такой же массив. Соответственно с него мне и выделили раздельчик на 300Гб - благо еще была возможность. Для того, чтобы подмаунтить его коллега использовал ioscan, insf , funC -disk и sam. Саначала создал volume group vg01, а в ней и раздел lvol9 с монтированием его в /dmp. Дальше дело техники - expdp и ipmdp по сети.
Кстати, impdp по сети с дамп-файлом еще делать не приходилось и надеюсь все сработает - щас пока молотит expdp. Через некоторое время добавлю продолжение.

Перенос базы в новую ASM_DISKGROUP

После того, как был добавлен новый LUN, был настроен автостарт базы осталось решить последнюю проблему - необходимо перенести базу из текущих asm_diskgroups, поднятых на RAID0 в новую asm_diskgroup, созданную на базе нового добавленного LUN'а RAID1.
При подготовке к данному переносу почитал доку, ноты металинка и провел ряд тестов на своей тестовой базе в VMVare-машине. В результате составил след.инструкцию, которую и использовал при работе с продакшн базой.
====
Задача: Перенести базу в новую asm_diskgroup
Данные: Имя новой asm_diskgroup - EVA01R1


1) Сделать бэкап control- файла

SQL> select name from v$controlfile;
SQL> alter database backup controlfile to '+EVA01R1';

2) Задать новое месторасположение control-файла в spfile

SQL> alter system set control_files='+EVA01R1\ITC\CONTROLFILE\CONTROL01.CTL' SCOPE=SPFILE;

Прим. если spfile не используется экземпляром, то прописать в его init.ora

3) Восстановить новый из старого control-файла


$ rman target /
RMAN > shutdown immediate;
RMAN > startup nomount;
RMAN> restore controlfile from '+EVA02/itc/controlfile/current.266.610247845';

4) Запустить копирование базы

RMAN> alter database mount;
RMAN> backup as copy database format ' +EVA01R1 ';

5) Переключить базу на копию

RMAN> switch database to copy;
RMAN> RUN
{
SWITCH TEMPFILE 1 TO '+EVA01R1';
}


6) Добавить в init.ora
параметр Db_create_file_dest=+eva01r1

7) Открыть базу
RMAN> alter database open;

8) Добавить в новую asm_diskgroup зеркальные копии онлайн-логов во всего журнальные группы экземпляра

alter database add logfile member ' +EVA01R1 ' to group 1 ;
alter database add logfile member ' +EVA01R1 ' to group 2;
alter database add logfile member ' +EVA01R1 ' to group 3 ;
alter database add logfile member ' +EVA01R1 ' to group 4 ;
alter database add logfile member ' +EVA01R1 ' to group 5 ;

9) Переключить журнал
alter system archive log current

10) Удалить старые копии журналов из старой asm_diskgroup

Можно использовать скрипт (здесь старая группа +EVA02)

declare
strSQL varchar2( 200 );
begin
for pList in (select member from v$logfile where member like '+EVA02/%' ) loop
strSQL:= 'alter database drop logfile member "' || pList.member || '"' ;
begin
EXECUTE IMMEDIATE strSQL;
end;
end loop;
end;

или вручную через

alter database drop logfile member '+EVA02/itc/onlinelog/group_1.256.609887989’
(имя файла изменять на свое)

Проверить остались ли старые файлы
select member from v$logfile where member like '+EVA02/%'

11) Переместить файл block_change_tracking

SQL> select status,filename
from v$block_change_tracking;

SQL> alter database disable block change tracking

SQL> alter database enable block change tracking
using file '+EVA01R1' reuse;


12) Проверить месторасположение всех фалов

select name from v$controlfile
union
select name from v$datafile
union
select name from v$tempfile
union
select member from v$logfile
union
select filename from v$block_change_tracking


13) Удалить все старые дисковые группы как ненужные

SQL> drop diskgroup eva01 including contents;
SQL> drop diskgroup eva02 including contents;

Добавление восьмого LUN'а с EVA5000 в Centos (ПРОДОЛЖЕНИЕ)

Вчера делал перенос базы в новую ASM дисковую группу как раз на этом сервере с его перезагрузкой. Тогда остались вопросы по поведению после ребута:
1) Похватится ли 8-й LUN системой?
2) Создастся ли /dev/mpath/3600508b4001039d90000600000d20000p1 , на базе которого должен создастся /dev/raw/raw17 ?
Ответы на все отрицательные :( Хотя после установки max-scsi-luns=255 ответы должны были быть положительными.
Пришлось пока просто прописать автостартап-скрипты для добавления 8-го LUNа и для монтирования с него raw-девайса для новой дисковой группы ASM Oracle. Как раз на нее и переливал впоследствии базу RMAN-ом.

[root@vld-olap-1 init.d]# cat /etc/init.d/addscsilun
#!/bin/sh
#
# chkconfig: 2345 1 99
# description: Adds new scsi LUN
#

/bin/echo "scsi add-single-device 0 0 0 8" > /proc/scsi/scsi
/bin/echo "scsi add-single-device 0 0 1 8" > /proc/scsi/scsi
/bin/echo "scsi add-single-device 1 0 0 8" > /proc/scsi/scsi
/bin/echo "scsi add-single-device 1 0 1 8" > /proc/scsi/scsi

#chkconfig --add addscsilun
проапдейтил скрипт маунта нового раздела в raw17 и все конечно заработало и проблема закрыта, но ... вопрос почему же 8-й LUN не подхватился системой после ребута остался нерешенным.

Смена пароля SYS экземпляра ASM

[oracle@mysrv dbs]$ orapwd file=$ORACLE_HOME/dbs/orapw+ASM password=sys force=y

Добавление восьмого LUN'а с EVA5000 в Centos

После включения поддержки ядром max_scsi_luns для автоматического подключения scsi-разделов презентовали дополнительный LUN на основе, которого нужно было сделать asm_diskgroup. Как я это сделал.
1) Вручную добавил данный LUN через
echo "scsi add-single-device 0 0 0 8" > /proc/scsi/scsi
echo "scsi add-single-device 0 0 1 8" > /proc/scsi/scsi
echo "scsi add-single-device 1 0 0 8" > /proc/scsi/scsi
echo "scsi add-single-device 1 0 1 8" > /proc/scsi/scsi

после чего появился файл /dev/dm-14
2) Вручную добавил вь-14
# multipathd -k
multipathd> add map dm-14
ok
после чего в /dev/mpath/ появилась ссылка на /dev/dm-14

3) Создал партицию из появившейся ссылки, т.е. в моем случае
# fdisk /dev/mpath/3600508b4001039d90000600000d20000
выдели все доступное пространство от первого до последнего цилиндра
Дал команду #partprobe

После чего я ожидал увидеть /dev/mpath/3600508b4001039d90000600000d20000p1, но этого не произошло.
Поэтому очень важно увидеть создание данного файла после ребута, т.к. именно после его создания startup-скриптами будет создан raw-девайс, на базе которого создается asm_diskgroup.

А пока я создал вручную raw через
# raw /dev/raw/raw17 /dev/mpath/3600508b4001039d90000600000d20000

А далее под oracle и ORACLE_SID=+asm создал группу
SQL> create diskgroup eva01r1 external redundancy disk /dev/raw/raw17;

Теперь нужно проверить во время ночных работ с перезагрузкой сервера и переливкой RMAN-ом базы в данную asm_diskgroup следующее:
1) Похватится ли 8-й LUN системой?
2) Создастся ли /dev/mpath/3600508b4001039d90000600000d20000p1 , на базе которого должен создастся /dev/raw/raw17 ?

Скрипт создания raw

cnt=10
for md in `ls /dev/mpath/*p1`
do
raw /dev/raw/raw$cnt $md
cnt=`expr $cnt + 1`
done;

Продолжение следует ...

per_free in tablespace/autoextent on

Запустив запрос на проверку свободной пространства в ТС
SELECT F.TABLESPACE_NAME,TO_CHAR ((T.TOTAL_SPACE - F.FREE_SPACE),'999,999') "USED (MB)",
TO_CHAR (F.FREE_SPACE, '999,999') "FREE (MB)",
TO_CHAR (T.TOTAL_SPACE, '999,999') "TOTAL (MB)",
TO_CHAR ((ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)*100)),'999')||' %' PER_FREE
FROM (SELECT TABLESPACE_NAME, ROUND (SUM (BLOCKS*(SELECT VALUE/1024
FROM V$PARAMETER WHERE NAME = 'db_block_size')/1024) ) FREE_SPACE
FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME) F,
(SELECT TABLESPACE_NAME,ROUND (SUM (BYTES/1048576)) TOTAL_SPACE
FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME ) T
WHERE F.TABLESPACE_NAME = T.TABLESPACE_NAME
обнаружил пару ТС с 0% в значении PER_FREE
Вопрос: как проверить выставлен ли autoextent в файлах данного ТС?
Ответ: select * from dba_data_files

umask и Vintela VAS

При установке VAS у пользователей AD их id в Unix-системах начинаются с 1001.
Согласно Red Hat Knowledgebase Если id пользователя более, чем 99, то umask по-умолчанию должен быть 002, иначе 022 (см./etc/bashrc), но umask у пользователей VAS на CentOS упорно 022.

Вследствие чего возникает проблема, когда пользователь группы VAS не может изменить (удалить) файлы, созданные другим пользователем этой же группы VAS.
Т.е. пользователь VAS должен либо давать команду umask 002 (666-002=664), чтобы его коллеги по VAS-группе могли менять созданные им файлы либо подправить свой /home/user/.bashrc путем добавления в конце строки umask 002.
Но юзеры никак не хотят это принять и упорно ругают VAS :) Можно их понять ....

Надо подправить настройки для вновь создаваемых пользователей для Linux в
/etc/skel/.bashrc, откуда берет настройки /etc/default/useradd, просто добавив в конце строку umask 002.
А для тех пользователей, которые уже зарегились подправить их /home/AD-user/.bashrc

Куда сыпятся логи стартап-скриптов в HP-UX?

При тестировании скрипта автостарта ASM-экземпляра Oracle (да и наверняка других самописных) полезно знать, что HP-UX логгирует записи о стартовых скриптах в /etc/rc.log. Кто встречал ошибку SQL> ORA-29701: unable to connect to Cluster Manager, тот поймет в чем польза этого файлика :)

Ссылки на БобрДобр

Удобный сервис - БобрДобр. Во всяком случае так позиционируется и на первый взгяд так и есть. Во всяком случае есть возможность "уволить" тэг "Links" :)

Ссылки BASH Shell Script Directory

http://bash.cyberciti.biz/