Привет.
Несколько дней назад при установке Oracle Business EE Suite11g столкнулись со следующей проблемой. При устанавке на тестовый сервер (MSWin 2003 R2 x86) процедура конфигурации домена зависала на первом же шаге - создание домена.
Изучение лога (файла, с расширением OUT) показало, что в логе все завершается строками.
Starting AdminServer
Starting the domain ...
DEBUG : Loading the 32 bit dll here
При этом процедура установки и конфигурации выполнялась на других серверах уже несколько раз. Чего только не делали - ничего не помогало.
Оказалось, что установка Oracle Business EE Suite11g (впрочем это требование справедливо для установки и Weblogic) необходимо, чтобы имя сервера (hostname) не содержало символов подчеркивания.
Изменили имя - все заработало...
суббота, 27 ноября 2010 г.
Oracle Support Master Notes Blog
Привет.
Обнаружил весьма полезный ресурс -Oracle DB/EM Troubleshooting
Содержит Support Master Notes по различным темам.
Очень полезными для меня оказались статьи по проблемам производительности DataBase.
Только ценность этот блог будет иметь только для тех, кто имеет доступ к metalink (support).
Удачи.
Обнаружил весьма полезный ресурс -Oracle DB/EM Troubleshooting
Содержит Support Master Notes по различным темам.
Очень полезными для меня оказались статьи по проблемам производительности DataBase.
Только ценность этот блог будет иметь только для тех, кто имеет доступ к metalink (support).
Удачи.
пятница, 12 ноября 2010 г.
Oracle BI EE 11g. Learning Library. Новые примеры
Привет.
Сегодня заметил публикацию двух новых Tutorial по теме Oracle BI EE 11g.
1. Creating a Repository Using the Oracle BI Administration Tool. Опубликован 10 ноября 2010.
2. Creating Analyses and Dashboards. Опубликован 29 октября 2010.
Приятного просмотра. )))
Сегодня заметил публикацию двух новых Tutorial по теме Oracle BI EE 11g.
1. Creating a Repository Using the Oracle BI Administration Tool. Опубликован 10 ноября 2010.
2. Creating Analyses and Dashboards. Опубликован 29 октября 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)