What a pid is using port.sh

Этот небольшой скрипт позволит узнать, какой PID занял порт на сервере Solaris:

#!/bin/ksh
#------
line='---------------------------------------------'
pids=$(/usr/bin/ps -ef | sed 1d | awk '{print $2}')
#------
if [ $# -eq 0 ]; then
read ans?"Enter port you would like to know pid for: "
else
ans=$1
fi
#------
for f in $pids
do
/usr/proc/bin/pfiles $f 2>/dev/null | /usr/xpg4/bin/grep -q "port: $ans"
if [ $? -eq 0 ]; then
echo $line
echo "Port: $ans is being used by PID:\c"
/usr/bin/ps -ef -o pid -o args | egrep -v "grep|pfiles" | grep $f
fi
done

Для RH проще
netstat -nlp | grep :1521
Вывод
tcp 0 0 :::1521 :::* LISTEN 32548/tnslsnr

Duplicate DB from backupset.

1. Копируем Бекапсет с арклогами и источника на приёмник.

2. Определяем переменные окружения (oracle_home и oracle_sid)

2. Проверяем параметры

SQL> show parameter convert

NAME TYPE VALUE
------------------------------------ ----------- ------------------------
db_file_name_convert string
log_file_name_convert string
pdb_file_name_convert string

3. Меняем параметры
SQL> alter system set db_file_name_convert='D:\Oradata\TEST','F:\Oradata\TEST' scope =spfile;
System altered.
SQL> alter system set log_file_name_convert='D:\Oradata\TEST','F:\Oradata\TEST' scope =spfile;
System altered.

4. Рестарт БД
SQL> shu immediate;
ORA-01507: database not mounted
ORACLE instance shut down.

SQL> startup nomount;
ORACLE instance started.

Total System Global Area 1.0289E+10 bytes
Fixed Size 2413360 bytes
Variable Size 5670702288 bytes
Database Buffers 4596957184 bytes
Redo Buffers 18542592 bytes

Проверяем применились ли настройки
SQL> show parameter convert

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string D:\Oradata\TEST, F:\Oradata\TEST
log_file_name_convert string D:\Oradata\TEST, F:\Oradata\TEST
pdb_file_name_convert string

5. rman AUXILIARY /
RUN
{
duplicate database to "TEST" nofilenamecheck
backup location 'D:\Backup\TEST';
}

…вывод на экран…

Прелесть данной конструкции в том, что мы може переименовать БД. Т.е. вместо «TEST» можно поставить «TEST2»

6. Убираем параметры
SQL> alter system reset db_file_name_convert scope=spfile;
System altered.
SQL> alter system reset log_file_name_convert scope=spfile;
System altered.

7. Restart instance and check parameters:
SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area 1.0289E+10 bytes
Fixed Size 2413360 bytes
Variable Size 5670702288 bytes
Database Buffers 4596957184 bytes
Redo Buffers 18542592 bytes
Database mounted.
Database opened.

SQL> show parameter convert

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string
log_file_name_convert string
pdb_file_name_convert string

—ready!

 

What is RH version?

What is RH version?
cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.8 (Santiago)

ln -s где_уже_что_то_находится по_какому_пути_линк_по_которому_нужен_доступ
ln -s /oracle/app/oracle/product/grid_12.2 /oracle/app/oracle/

Statspack. Установка и настройка.

«А у нас в квартире газ! А у вас?» А у нас Standard Edition!

Лишенные радости использования AWR (Automatic Workload Repository) в Enterprise Edition администраторы SE могут использовать набор утилит мониторинга производительности Statspack.

Установить Statspack
@%ORACLE_HOME%\rdbms\admin\spcreate

OR
@?/rdbms/admin/spcreate

Хорошо, установили, но статистика от этого собирается просто так не станет.
Что бы автоматом собиралась статистика:
@?/rdbms/admin/spauto.sql
Читать далее «Statspack. Установка и настройка.»

Повышенное ожидание log file sync. LGWR — Post/wait и Polling.

Version 11.2.0.3 , Windows 2008R2

Столкнулись с ситуацией повышенного log file sync wait.

Конечно написанное приложение далеко от идеала, и в БД очень много коммитов. Но раньше такой ситуации по ожиданиям не возникало, а код остался нетронутым.

Деградации в производительности дискового хранилища и сети не были найдены, всё железо стабильно продолжало работать. В алертлоге ничего путного тоже нет, только:
«Thu Mar 30 15:20:19 2017
Thread 1 cannot allocate new log, sequence 4824
Private strand flush not complete»
Читать далее «Повышенное ожидание log file sync. LGWR — Post/wait и Polling.»