Привет.
Обнаружил весьма полезный ресурс -Oracle DB/EM Troubleshooting
Содержит Support Master Notes по различным темам.
Очень полезными для меня оказались статьи по проблемам производительности DataBase.
Только ценность этот блог будет иметь только для тех, кто имеет доступ к metalink (support).
Удачи.
Показаны сообщения с ярлыком Oracle DB. Показать все сообщения
Показаны сообщения с ярлыком Oracle DB. Показать все сообщения
суббота, 27 ноября 2010 г.
среда, 3 ноября 2010 г.
Temporary change password или мысль о "всемогущих" админах
Привет.
Должен признаться, что на днях было разрушено одно мое заблуждение о невозможности подключения к базе данных с помощью учетной записи пользователя, пароль которой мне неизвестен.
Конец моему заблуждению положила ЭТА статья.
В ней описана возможность временной смены пароля у учетной записи и восстановления предыдущего пароля с помощью недокументированной возможности команды ALTER USER. Данная возможность была мною проверена на сервере Oracle DB 9.2.0.8
Вообщем действуем так:
1. Создаем пользователя для тестирования
create user TEST identified by test;
grant connect to test;
Далее будем считать, что пароль этого пользователя нам неизвестен и у нас существует ОЧЕНЬ БОЛЬШОЕ желание подключиться к базе данных от имени этого пользователя.
2. Получим значение колонки Password из представления DBA_USERS
select password from dba_users where username = 'TEST';
Query finished, retrieving results...
PASSWORD
------------------------------
7A0F2B316C212D67
1 row(s) retrieved
3. Сохраним полученной значение. Оно нам понадобиться для заметания следов...
4. Заменим на время пароль пользователя на придуманный нами.
alter user test identified by cooladmin;
5. Подключимся к базе данных и "совершим задуманное"....
6. Теперь надо замести следы и восстановить пароль пользователя, который мы не знаем...
Это делается с помощью следующей команды
alter user test identified by VALUES '7A0F2B316C212D67 ';
7. Вот и все... Во всех операциях, совершенных на шаге 5 "виноват" ничего не подозревающий TEST...
Начиная с этого момента начинаю серьезно задумываться над применением дополнительных механизмов защиты паролей пользователей в рабочих системах.
Удачи всем...
Должен признаться, что на днях было разрушено одно мое заблуждение о невозможности подключения к базе данных с помощью учетной записи пользователя, пароль которой мне неизвестен.
Конец моему заблуждению положила ЭТА статья.
В ней описана возможность временной смены пароля у учетной записи и восстановления предыдущего пароля с помощью недокументированной возможности команды ALTER USER. Данная возможность была мною проверена на сервере Oracle DB 9.2.0.8
Вообщем действуем так:
1. Создаем пользователя для тестирования
create user TEST identified by test;
grant connect to test;
Далее будем считать, что пароль этого пользователя нам неизвестен и у нас существует ОЧЕНЬ БОЛЬШОЕ желание подключиться к базе данных от имени этого пользователя.
2. Получим значение колонки Password из представления DBA_USERS
select password from dba_users where username = 'TEST';
Query finished, retrieving results...
PASSWORD
------------------------------
7A0F2B316C212D67
1 row(s) retrieved
3. Сохраним полученной значение. Оно нам понадобиться для заметания следов...
4. Заменим на время пароль пользователя на придуманный нами.
alter user test identified by cooladmin;
5. Подключимся к базе данных и "совершим задуманное"....
6. Теперь надо замести следы и восстановить пароль пользователя, который мы не знаем...
Это делается с помощью следующей команды
alter user test identified by VALUES '7A0F2B316C212D67 ';
7. Вот и все... Во всех операциях, совершенных на шаге 5 "виноват" ничего не подозревающий TEST...
Начиная с этого момента начинаю серьезно задумываться над применением дополнительных механизмов защиты паролей пользователей в рабочих системах.
Удачи всем...
вторник, 2 ноября 2010 г.
Трассировка чужой сессии в ORACLE
Привет.
Очень часто ко мне обращаются пользователи или наши тестировщики со следующей проблемой:
"У меня программа стала работать МЕДЛЕННО!"
При этом совсем нет времени на детальное изучение проблемы, да еще и рабочие сервера как правило работают с параметром sql_trace = false ...
В этом случае я для себя нашел следующее "экспресс"-решение.1. Просим пользователя "зайти" в программу
2. Находим sid и serial сессии пользователя ( select sid, serial# from v$session where <условия поиска> )
3. Выполняем такой PL/SQL блок
declare
-- 0/1/null <--> false/true/null
-- Boolean parameters are translated from/to integers:
sql_trace boolean := sys.diutil.int_to_bool(1);
begin
-- Call the procedure
dbms_system.set_sql_trace_in_session
(sid => 56,
serial# => 6656,
sql_trace => sql_trace);
end;
После его выполнения начинается трассировка указанной сессии.
4. Просим пользователя выполнить долгую операцию...
5. Ждем ...
6. Отключает трассировку, выполнив еще раз этот скрипт, указывая параметр sql_trace = 0
7. Находим в каталоге UDUMP сервера файл .trc
Имя файла содержит в себе идентификатор процесса операционной системы. Найти его можно так
SQL> select p.spid from v$session s, v$process p
2 where s.paddr=p.addr
3 and ...мои_критерии_отбора...
4 /
8. Обрабатываем этот файл утилитой TKPROF ( TKPROF <имя trc-файла> <имя выходного файла> )
9. В полученном файле анализируем финальные итоги, оценивая параметры CPU и ELAPSED
Например, сегодня я получил такую картину.
И итогах видно, что проблема ЕСТЬ и она сосредоточена во времени ожидания получения данных (20.85 сек)
Надо искать проблемные запросы.
10. В Window с помощью команды find "total" <имя выходного файла> >1.txt
ищем все строки, которые начинаются с "total" и сохраняем их в файл 1.txt
11. Бегло проматриваем этот файл и находим значения, которые по свей величине нас не устраивают.
Для моего сегодняшнего случая было 2 таких тотальных строки для двух запросов, которые занимали практически собой все время ожидания.
total 9 0.00 0.00 0 21 0 9
total 3 0.03 0.02 0 3 0 0
total 3 0.01 0.00 0 14 0 5
total 3 0.64 10.89 11848 17504 0 4
total 3 0.07 0.06 0 214 0 29
total 15 0.00 0.00 0 15 0 5
total 3 0.01 0.00 0 3 0 0
total 3 0.00 0.00 0 4 0 1
total 3 0.00 0.00 0 8 0 6
total 6 0.04 0.02 0 8 0 2
total 3 0.00 0.00 0 4 0 1
total 3 0.00 0.00 0 3 1 1
total 3 0.00 0.00 0 2 0 1
total 3 0.01 0.00 0 8 2 1
total 2 0.00 0.00 0 4 1 1
total 3 0.00 0.00 0 2 0 1
total 3 0.21 9.85 7760 12354 0 1
total 6 0.00 0.00 0 0 0 0
total 6 0.00 0.00 0 0 0 0
Дальше по этим значениям из этих строк в обработанном trace-файле находим проблемные запросы и разбираемся с ними.
Мне сегодня было достаточно построить два индекса...
ВСЕ...
По моему опыту с помощью этих нехитрых манипуляций решаются около 90 процентов замечаний по производительности серверов.
Вы можете спросить, а зачем выполнять 10 пункт. Ведь можно и в обработанном TRC-файле искать проблемные запросы. КОНЕЧНО МОЖНО. Не если таких запросов в одном trace несколько сотен, то проще бегло просмотреть или обработать только тотал, а потом перейти к деталям...
Удачи.
Очень часто ко мне обращаются пользователи или наши тестировщики со следующей проблемой:
"У меня программа стала работать МЕДЛЕННО!"
При этом совсем нет времени на детальное изучение проблемы, да еще и рабочие сервера как правило работают с параметром sql_trace = false ...
В этом случае я для себя нашел следующее "экспресс"-решение.
2. Находим sid и serial сессии пользователя ( select sid, serial# from v$session where <условия поиска> )
3. Выполняем такой PL/SQL блок
declare
-- 0/1/null <--> false/true/null
-- Boolean parameters are translated from/to integers:
sql_trace boolean := sys.diutil.int_to_bool(1);
begin
-- Call the procedure
dbms_system.set_sql_trace_in_session
(sid => 56,
serial# => 6656,
sql_trace => sql_trace);
end;
После его выполнения начинается трассировка указанной сессии.
4. Просим пользователя выполнить долгую операцию...
5. Ждем ...
6. Отключает трассировку, выполнив еще раз этот скрипт, указывая параметр sql_trace = 0
7. Находим в каталоге UDUMP сервера файл .trc
Имя файла содержит в себе идентификатор процесса операционной системы. Найти его можно так
SQL> select p.spid from v$session s, v$process p
2 where s.paddr=p.addr
3 and ...мои_критерии_отбора...
4 /
8. Обрабатываем этот файл утилитой TKPROF ( TKPROF <имя trc-файла> <имя выходного файла> )
9. В полученном файле анализируем финальные итоги, оценивая параметры CPU и ELAPSED
Например, сегодня я получил такую картину.
И итогах видно, что проблема ЕСТЬ и она сосредоточена во времени ожидания получения данных (20.85 сек)
Надо искать проблемные запросы.
10. В Window с помощью команды find "total" <имя выходного файла> >1.txt
ищем все строки, которые начинаются с "total" и сохраняем их в файл 1.txt
11. Бегло проматриваем этот файл и находим значения, которые по свей величине нас не устраивают.
Для моего сегодняшнего случая было 2 таких тотальных строки для двух запросов, которые занимали практически собой все время ожидания.
total 9 0.00 0.00 0 21 0 9
total 3 0.03 0.02 0 3 0 0
total 3 0.01 0.00 0 14 0 5
total 3 0.64 10.89 11848 17504 0 4
total 3 0.07 0.06 0 214 0 29
total 15 0.00 0.00 0 15 0 5
total 3 0.01 0.00 0 3 0 0
total 3 0.00 0.00 0 4 0 1
total 3 0.00 0.00 0 8 0 6
total 6 0.04 0.02 0 8 0 2
total 3 0.00 0.00 0 4 0 1
total 3 0.00 0.00 0 3 1 1
total 3 0.00 0.00 0 2 0 1
total 3 0.01 0.00 0 8 2 1
total 2 0.00 0.00 0 4 1 1
total 3 0.00 0.00 0 2 0 1
total 3 0.21 9.85 7760 12354 0 1
total 6 0.00 0.00 0 0 0 0
total 6 0.00 0.00 0 0 0 0
Дальше по этим значениям из этих строк в обработанном trace-файле находим проблемные запросы и разбираемся с ними.
Мне сегодня было достаточно построить два индекса...
ВСЕ...
По моему опыту с помощью этих нехитрых манипуляций решаются около 90 процентов замечаний по производительности серверов.
Вы можете спросить, а зачем выполнять 10 пункт. Ведь можно и в обработанном TRC-файле искать проблемные запросы. КОНЕЧНО МОЖНО. Не если таких запросов в одном trace несколько сотен, то проще бегло просмотреть или обработать только тотал, а потом перейти к деталям...
Удачи.
Подписаться на:
Сообщения (Atom)