Temp Usage

by session:

SELECT S.sid || ',' || S.serial# sid_serial, S.username, S.osuser, P.spid, S.module,
S.program, SUM (T.blocks) * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
COUNT(*) sort_ops
FROM v$sort_usage T, v$session S, dba_tablespaces TBS, v$process P
WHERE T.session_addr = S.saddr
AND S.paddr = P.addr
AND T.tablespace = TBS.tablespace_name
GROUP BY S.sid, S.serial#, S.username, S.osuser, P.spid, S.module,
S.program, TBS.block_size, T.tablespace
ORDER BY sid_serial;

когда арклоги не нужны

RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process

SQL>SELECT CAPTURE_NAME, CAPTURE_TYPE, STATUS, to_char(REQUIRED_CHECKPOINT_SCN,'999999999999999')as REQ_SCN ,to_char(OLDEST_SCN,'999999999999999')as OLDEST_SCN FROM DBA_CAPTURE;

выдаёт 0 строк

отключение политики

CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;

хоть и отругается

RMAN-08591: warning: invalid archived log deletion policy

но удаление архивных логов пройдёт на ура

RMAN> DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE 22097 THREAD 1;

initial postgres beauty

после установки свежего экземпляра postgresql отображение в консоли psql не очень радует на больших строках, которые не вмещаются в экран 🙂
поправим пейджинг:

cd
echo "\setenv PAGER 'less -XS'" > .psqlrc

поправим bash prompt string:

echo 'PS1=["\u@\h \w]\$ "' >> .bash_profile

Restore datafile on STANDBY from PRIMARY service

Не применяются арклоги на STANDBY сервере:

Reading datafile '/u01/app/oracle/oradata/databasename/superfile_edr_tbls01.dbf' for corruption at rdba: 0x054018ae (file 21, block 6318)
Reread (file 21, block 6318) found same corrupt data (logically corrupt)
Mon Jun 14 04:28:27 2021
Checker run found 1 new persistent data failures
ERROR: ORA-00756 detected lost write of a data block
Slave exiting with ORA-756 exception
Mon Jun 14 04:28:32 2021
Errors in file /u01/app/oracle/diag/rdbms/databasename_bk/databasename/trace/databasename_pr02_22763.trc:
ORA-00756: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 21, block# 6318, file offset is 51757056 bytes)
ORA-10564: tablespace SUPERFILE_EDR_TBLS
ORA-01110: data file 21: '/u01/app/oracle/oradata/databasename_bk/superfile_edr_tbls01.dbf'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 21388901

При живом PRIMARY восстановим файл с него на STB. Подключимся RMAN к стендбай серверу и дадим команду:

restore datafile 21 from service main;

alter database recover managed standby database disconnect from session;

profit

Добавление ASM диска

Администратор сервера подключил диск к серверу. Что же делать DBA?
Давайте просмотрим на наши блочные устройства:

# lsblk

NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
...
sdf                            8:80   0     3T  0 disk
└─sdf1                         8:81   0     3T  0 part
sdo                            8:224  0     3T  0 disk
sdd                            8:48   0     3T  0 disk
└─sdd1                         8:49   0     3T  0 part
...

Читать далее «Добавление ASM диска»

Запросы для АНДУ / Oracle UNDO queries

В редакцию поступил вопрос:
«ORA-30036: unable to extend segment by 8 in undo tablespace ‘UNDO_2’ at»

давайте поглядим, что можно посмотреть, может чего и увидим:

Мой любимый запрос, позволяет определить основного потребителя с разбивкой по инстансам (актуально для RAC конфигурации) :
select s.INST_ID,
s.sid,
s.username,
round( sum(ss.value) / 1024 / 1024 ,1)as undo_size_mb
from gv$sesstat ss
join gv$session s on s.sid = ss.sid AND s.INST_ID=ss.INST_ID
join gv$statname stat on stat.statistic# = ss.statistic#
where stat.name = ‘undo change vector size’
and s.type <> ‘BACKGROUND’
and s.username IS NOT NULL
group by s.INST_ID, s.sid, s.username
ORDER BY 4 desc

to be updated….

Get long lasting sql execution plans on email / Получить план долгих запросов на почту

This is upgraded version of nice utility procedure.
It sends execution plans if query is running longer then specific amount of time.
A trick was to split a big email into chunks as Oracle DB can’t send emails more than 32Kb.

Действия для SYS/SYS user actions:
1) Если у нас PDB, то выбираем необходимую:
PDBs action required:
alter session set container = OUR_PDB;

2) Обеспечиваем пользователя SYSTEM необходимыми правами. Хоть SYSTEM может селектить из вьюшек, гранты всё равно давать необходимо. Можно указать любого другого пользователя.
Provide required grants to system (or any other) user:

grant select on v_$sql to system;
grant select on v_$sql_plan to system;
grant select on v_$sql_plan_statistics_all to system;
grant select on V_$SESSION to system;
grant select on V_$instance to system;

3.1) Устанавливаем UTL_MAIL / Lets install UTL_MAIL:
Читать далее «Get long lasting sql execution plans on email / Получить план долгих запросов на почту»

Быстрое удаление пользователя Oracle

Оригинал: Drop User Fast (in parallel) но как-то раз столкнулся с тем, что ресурс был недоступен, потому решил продублировать сюда.

Удаление Оракловой схемы может занять о-очень много времени, если просто использовать «DROP USER yourmamuser CASCADE». Фишка в том, что таким способом объекты схемы удаляются последовательно.
Ниже прикреплён скрипт которым можно дропать схемы в Oracle через ПАРАЛЛЕЛЬНОЕ удаление всех объектов пользователя. Очень пригождается когда у нас в схемых овер-много (500к+) таблиц

Пошаговый мануал:
0. Укажите корректные переменные окружения
1. Распакуйте архив
2. Запустите скрипт «mk_dropusertabs.ksh <ПОЛЬЗОВАТЕЛЬ> <ПАРАЛЛЕЛЬНОСТЬ>«, где ПОЛЬЗОВАТЕЛЬ это имя схемы для удаления, а ПАРАЛЛЕЛЬНОСТЬ это степень параллельности которую хотим применить. Например, «./mk_dropusertabs.ksh yourmam 8» создаст 8 файлов с командами для удаления таблиц
3. Запустите скрипт «mk_dropuserviews.ksh <ПОЛЬЗОВАТЕЛЬ> <ПАРАЛЛЕЛЬНОСТЬ>» для создания файлов команд на удаление представлений
4. Запустите «dropusertabes.ksh <ПОЛЬЗОВАТЕЛЬ>»
5. Запустите «dropuserviews.ksh <ПОЛЬЗОВАТЕЛЬ>»
6. Дропните схему: «DROP USER <ПОЛЬЗОВАТЕЛЬ>;»

Скачать скрипт: dropuserfast