Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 И снова Statistics  [new]
Админ-студент
Guest
Прихожу на практику в фирму....
там стоит Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production

Заметил, что в одном месте клиентское приложение просто вешается.....
отследил на каком запросе оно вешается... запустил этот запрос из СКЛ+
результат в 400 строк получил через... 15 минут!!!!!!

запустил:
SELECT Owner, last_analyzed
FROM dba_tables
WHERE owner = 'MYSCHEMANAME' 
;
В результате увидет, что поле last_analyzed везде пустое....
то же самое и на всех остальных схемах....
это значит - статистики нету что ли????
Разве такое возможно?????

Решил помудрить и написать скрипт для сбора статистики.....
Хочу получить "пинук" со стороны гуру данного форуму... по вопросу = все ли верно я сделал???

Вот мой скрипт (прошу больно не пинать - все же я стажируюсь)

_start.cmd
SQLPLUS "SYS/******l AS SYSDBA" @Statistic.sql 
Statistic.sql
SET LINESIZE 100
SET HEADING OFF
@plan.sql
SPOOL Stats.log
@plan.log
SPOOL OFF
SPOOL result.log
SELECT owner, table_name, last_analyzed
	FROM dba_tables
	WHERE owner NOT IN ('SYS', 'SYSTEM','DBSNMP','OUTLN', 'SCOTT') 
	ORDER BY owner ;
SPOOL OFF

DISCONNECT
EXIT

plan.sql
SPOOL plan.log

SELECT 'PROMPT Deleting schema statistics' ,
	   count(*), ' schemas' 
	FROM dual,
	all_users
	WHERE username NOT IN ('SYS', 'SYSTEM','DBSNMP','OUTLN', 'SCOTT')
	;

SELECT 'EXEC DBMS_STATS.DELETE_SCHEMA_STATS('||CHR(39)||username||CHR(39)||');'
	FROM all_users
	WHERE username NOT IN ('SYS', 'SYSTEM','DBSNMP','OUTLN', 'SCOTT')
	;

SELECT 'PROMPT gathering schema statistics' ,
	   count(*), ' schemas' 
	FROM dual,
	all_users
	WHERE username NOT IN ('SYS', 'SYSTEM','DBSNMP','OUTLN', 'SCOTT')
	;

SELECT 'EXEC DBMS_STATS.GATHER_SCHEMA_STATS('||CHR(39)||username||CHR(39)||');'
	FROM all_users
	WHERE username NOT IN ('SYS', 'SYSTEM','DBSNMP','OUTLN', 'SCOTT')
	;

SPOOL OFF

Возникают, по неопытности вот такие вопросы
1 - достаточно ли собирать статистику раз в неделю (активность работы юзеров в базе невелика)
2 - верно ли то, что я исключил из сбора статистики 'SYS', 'SYSTEM' ?
3 - ну... и может я еще чего не учел?????
11 дек 06, 09:30    [3516654]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Dimka9
Member

Откуда: Владивосток
Сообщений: 1851
главное, что Вы не учли на мой взгляд:
входит ли в ваши обязанности настройка БД?

Если да, то только после этого стоит продолжать разговор.
11 дек 06, 09:38    [3516689]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 116342
И еще неплохо проверить OPTIMIZER_GOAL
11 дек 06, 09:42    [3516714]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18487
И более того -- ты уверен, что приложение специально не разрабатывалось под RBO
А то соберешь статистику -- этот запрос залетает, а все остальные затормозят
В любом случае подобные телодвижения необходимо сначала проверять в тестовом окружении

По поводу скрипта: а нафига удаляешь статистику, если ее пересобираешь?
Далее: открой для себя execute immediate (вместо spool), хотя для проверки может и имеет смысл выводить сначала в файл

Частота сбора статистики зависит от частоты изменения распределения данных в таблицах. Отслеживать можно через ALL_TAB_MODIFICATIONS, устатновив на таблицы MONITORING

Статистику не надо собирать только по словарю (SYS), да и то в 9-ке это уже не столь критично (хотя, конечно версия 9.2.0.1.0 слишком кривовата)
11 дек 06, 09:46    [3516731]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Админ-студент
Guest
автор
входит ли в ваши обязанности настройка БД?


Если честно == да!!!!

dmidek
И еще неплохо проверить OPTIMIZER_GOAL


мне стыдно, но я не в курсе, что это такое....

Вячеслав Любомудров
И более того -- ты уверен, что приложение специально не разрабатывалось под RBO
А то соберешь статистику -- этот запрос залетает, а все остальные затормозят


Простите, а как узнать, разрабатывалось ли под RBO?
Хотя, смею предположить, что это не так..
ибо первоначально база была на 7-ке, потом перевелась на 8.0.5, (это еще до меня было), и, теперь на 9,9 стала...

Вячеслав Любомудров
По поводу скрипта: а нафига удаляешь статистику, если ее пересобираешь?

Да где-то прослышал, что надежней сперва удалить, а потом собрать.... но, конечно не уверен обязательно ли это...

Вячеслав Любомудров
Далее: открой для себя execute immediate (вместо spool), хотя для проверки может и имеет смысл выводить сначала в файл


Ну это не для проверки.. а просто увидел такой метод.. и, стал им пользоваться......
11 дек 06, 09:56    [3516766]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Админ-студент
Guest
dmidek
И еще неплохо проверить OPTIMIZER_GOAL


М-да... OPTIMIZER_MODE у меня = CHOOSE

F rfr gjcvjnhtnm OPTIMIZER_GOAL не нашел еще
11 дек 06, 10:19    [3516914]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Dimka9
Member

Откуда: Владивосток
Сообщений: 1851
OPTIMIZER_GOAL:

Ты чего хочешь добиться? Если все работает замечательно а только один запрос тормозит - то не нужно глобальных измененений - оптимизируй сам запрос.

Если все тянется от 7 версии и upgrade делался без особых телодвижений - то скорее всего в основе RBO.

И у тебя должны быть веские основания что-бы собирать статистику (переводить на CBO). В первом посте я их не увидел.
11 дек 06, 10:25    [3516942]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Админ-студент
Guest
Dimka9
OPTIMIZER_GOAL:

Ты чего хочешь добиться? Если все работает замечательно а только один запрос тормозит - то не нужно глобальных измененений - оптимизируй сам запрос..


да Бог его знает, чего я хочу - данный запрос я посмотреть-то могу. но он "зашит в клиентское приложение", и, не имея исходников как я могу его оптимизировать????

Одно только вижу - план этого запроса со статистикой и без нее - разный.....

Dimka9

Если все тянется от 7 версии и upgrade делался без особых телодвижений - то скорее всего в основе RBO.
И у тебя должны быть веские основания что-бы собирать статистику (переводить на CBO). В первом посте я их не увидел.


основания на том, что некое приложение просто вешается при нажатии, на определенную кнопку (в которую "зашит " этот запрос.....)
а раз вешается == юзеры шачинают нам пинать...
11 дек 06, 10:54    [3517169]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Dimka9
Member

Откуда: Владивосток
Сообщений: 1851
без исходников смена RBO на CBO выглядит еще более забавным мероприятием.

вижу 2 вар.
1. спросить у разработчика.
2. провести тестирование работы системы с RBO, CBO сняв времена выполнения всех критичных операций. И только после этого можно быть увереным что "эта кнопочка" стала отвечать", а другие "5 штук зависли".

PS ты же знаешь что выполняется по кнопке. Может проще индекс построить или еще чего (тоже осторожно). Это все же не так глобально как собрать статистику.
11 дек 06, 11:05    [3517245]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Админ-студент
Guest
Dimka9
без исходников смена RBO на CBO выглядит еще более забавным мероприятием.

вижу 2 вар.
1. спросить у разработчика.


спросили.. именно спросили "от чего данное приложение работает с тормозами...."
его ответ "Виноваты админы.. в частности они несвоевременно собирают статистику...."
и что теперь???
Вы полагаете, что это скорей всего RBO, для RBO статистика вредна...?
Разработчик говорит, то что только что я написал.. и????

Заметьте, что разработчик как правило отвечает "ничего не знаю.. у нас все работает...."
11 дек 06, 11:56    [3517703]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 116342
Админ-студент
Вы полагаете, что это скорей всего RBO, для RBO статистика вредна...?


У Вас OPTIMIZER_MODE=CHOOSE. (по- русски - выбор).
Критерием этого выбора является отсутствие (RBO) или наличие (CBO) статистики.
Сейчас у Вас без статистики работает RBO. Собрав статистику Вы поменяете
RBO на CBO. Проведенная одномоментно , эта акция чревата непредсказуемыми
последствиями для приложения , вплоть до полной остановки.

(c) "Не делайте резких движений",
а лучше займитесь анализом тормозного запроса.
11 дек 06, 12:02    [3517745]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18399
Админ-студент
Вячеслав Любомудров
И более того -- ты уверен, что приложение специально не разрабатывалось под RBO
А то соберешь статистику -- этот запрос залетает, а все остальные затормозят

Простите, а как узнать, разрабатывалось ли под RBO?
Хотя, смею предположить, что это не так..
ибо первоначально база была на 7-ке, потом перевелась на 8.0.5, (это еще до меня было), и, теперь на 9,9 стала...

Осмелюсь предположить что это ИМЕННО ТАК.
Хотя разработчики и отвечают про несвоевременный сбор статистики, но полностью доверять этому формальному отмазу я бы не стал.
Откройте документацию на систему, найдите перечень регламентных работ и посмотрите, входит ли в них сбор статистики. Если входит - должны быть четкие инструкции как именно должно проводить сей процесс. Если не написано - запросите исчерпывающе инструкции у разработчика системы.
Как начинающему админу, Вам в первую голову следует овладеть самым главным искусством DBA - умением прикрывать задницу. Все остальное - сугубо потом.
ИМХО.
11 дек 06, 12:06    [3517777]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Админ-студент
Guest
dmidek
Админ-студент
Вы полагаете, что это скорей всего RBO, для RBO статистика вредна...?


У Вас OPTIMIZER_MODE=CHOOSE. (по- русски - выбор).
Критерием этого выбора является отсутствие (RBO) или наличие (CBO) статистики.
Сейчас у Вас без статистики работает RBO. Собрав статистику Вы поменяете
RBO на CBO. Проведенная одномоментно , эта акция чревата непредсказуемыми
последствиями для приложения , вплоть до полной остановки..


Судя по тому, что 4 дня назад собрал статистику на одной из рабочих баз, коиз есть много но они структурно одинаковые....
"тупой" АРМ заработал.. остальные - каюсь не проверял, но там же юзера работают... раз они за эти дни ни разу не сообщили о тормозах... значит пока что ничего не остановилось.....

Вполне вероятно, что я поступил верно.. или же.. с точностью до наоборот.....

Вобщем получается 50/50.. как и в жизни... (либо жив - либо мертв )

Документации, о которой говорил andrey_anonymous , как мне кажется не существует в природе... (неужто так не бывает???)

dmidek

(c) "Не делайте резких движений",
а лучше займитесь анализом тормозного запроса.


анализировать тормозной запрос.. без возможности его изменить??? есть ли в этом смысл?????
Я его запустил - получил результат, упростил практически до минимума (смотрел в сторону того, чтобы получить ТАКОЙ ЖЕ ТОЧНО результат), вроде получилось..
то есть
1 сложный тормозной запрос зает ЭН записей
2 - мой упрощенный дает те же ЭН записей..
и что????
Всунуть его в приложение, не имея исходников - не вижу возможности..
отослать его разработчикам === "открыть собственную задницу + раздвинуть пошире ноги...."
а что???: никто из вас не был разработчиком??? не встречалить с утверждением "моя программа самая правильная, а каждый, кто ее попытается изменить - му**ло страшное..."
11 дек 06, 12:23    [3517927]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Щукина Анна
Member

Откуда:
Сообщений: 1490
Админ-студент
Документации, о которой говорил andrey_anonymous , как мне кажется не существует в природе... (неужто так не бывает???)
Я бы вот так сформулировала мысль:
"Документация на сопровождаемую систему?!?! Не уж-то такое бывает!"
11 дек 06, 12:26    [3517943]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Vladimirgs
Member

Откуда: Казань
Сообщений: 694
А с чем боретесь если не секрет? Что за софт?
11 дек 06, 12:42    [3518091]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18399
Админ-студент
анализировать тормозной запрос.. без возможности его изменить??? есть ли в этом смысл?????

Вы может и не имеете возможности изменить текст запроса, но имеете достаточно много возможностей по изменению плана исполнения. В частности, сбор статистики - это один из методов такого действа. Что-то вроде большой дубины, которой можно охлобучить целую кучу запросов.
Есть и другие способы - более тонкие и требующие специальных знаний, но есть. Это и построение outlines, и "подкладывание" статистики, обеспечивающей более эффективные планы чем реальная, и создание мат. представлений... и т.д.
11 дек 06, 12:56    [3518220]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Админ-студент
Guest
andrey_anonymous

Есть и другие способы - более тонкие и требующие специальных знаний, но есть. Это и построение outlines, и "подкладывание" статистики, обеспечивающей более эффективные планы чем реальная, и создание мат. представлений... и т.д.


м-да..... пока нету этих спецзнаний....

а борюсь я с Power Obj
11 дек 06, 13:08    [3518341]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Vladimirgs
Member

Откуда: Казань
Сообщений: 694
Не знаю конечно как отнесутся гуру к моему предложению, но на мой взгляд, для понятия что творится с приложением и с базой, надо в течение часа активной работы поделать снимки с базы,
помониторить SQL запросом типа.
select t.SQL_TEXT, t.EXECUTIONS, t.DISK_READS, t.BUFFER_GETS from v$sql t order by t.DISK_READS desc, t.EXECUTIONS desc
Сразу будет понятно что к чему.


Не сочтите за рекламу, но может вам разжиться пакетом Quest Central ? Его представители рассылают бесплатно с триальными ключами на месяц. Для новичка это хороший набор визуального анализа производительности БД. Потом все равно возвращаемся к статспаку
11 дек 06, 13:34    [3518525]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Админ-студент
Guest
Vladimirgs
Не знаю конечно как отнесутся гуру к моему предложению, но на мой взгляд, для понятия что творится с приложением и с базой, надо в течение часа активной работы поделать снимки с базы,
помониторить SQL запросом типа.
select t.SQL_TEXT, t.EXECUTIONS, t.DISK_READS, t.BUFFER_GETS from v$sql t order by t.DISK_READS desc, t.EXECUTIONS desc
Сразу будет понятно что к чему.


спамибо.. хотя пока понимание туманное
11 дек 06, 13:51    [3518658]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Vladimirgs
Member

Откуда: Казань
Сообщений: 694
В Оракле существует несколько причин тормозов, все они взаимосвязаны, как правило, в первую очередь необходимо проверить:
1. Дисковую подсистему. Как разложены файлы, каково время доступа. Как часто переключаются логгруппы.
2. Память. Как она распределена, почему так, а не иначе. Как она используется.
3. Неверный запрос. Здесь определяющим является анализ плана запроса и представления "А как должно быть". Без обработки запросов на сервере вам будет очень сложно их оптимизировать или, если они не доступны к оптимизации, подстраивать структуру БД к ним.

Вообще может вам почитать Тома Кайта первую книгу, вторую главу. Там хорошо расписана архитектура и физика работы БД.
11 дек 06, 14:08    [3518784]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Vladimirgs
Member

Откуда: Казань
Сообщений: 694
Тем запросом что я вам дал вы можете оценить, какие запросы больше всего читают с диска, чаще всего запускаются. Посмотрите еще колонки этой вьюшки, там много чего интересного можно найти.
а вообще поглядите на такие параметры как
select * from v$sysstat t where t.STATISTIC# in (40, 41, 42, 122, 123, 186, 187, 188, 203, 204, 205, 206, 207, 225, 226, 233,234,235,236, 245, 246
) тоже иногда наводит на размышления.
Ну и инишник БД обязательно :-)
11 дек 06, 14:20    [3518874]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Админ-студент
Guest
ОК!!! спасибо всем!!!!! будем посмотреть
11 дек 06, 14:40    [3519012]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Админ-студент
Guest
вот еще капля.....

решил САМ, не дожидаясь юзеров проверить, а не затормозило лди в другом месте....

есть в одном из приложений так сказать критическое место - "Главная бухгалтерская книга"

как результат

1 - изначально нет статистики - книга считается 15 секунд

2 - собираю статистику

3 - книга считается 2,5 секунды

4 - удаляю статистику

5 - книга считается 15 секунд (это чтобы убедиться на 100%)

6 - собираю статистику - книга считается 2,5 секунды

(секундомер конечно не супер - на мобиле который... )

Так еперь как же судить? приложение на RBO было изначально создано???

Да, возможно и найдутся где-то тормоза.. но 2 критические точки пройденны... (кстати на длитьельность расчета этой книги жаловались юзера уже давно)
12 дек 06, 12:09    [3523170]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Dimka9
Member

Откуда: Владивосток
Сообщений: 1851
Я вижу проблему... и не в том что вы собираете/не собираете статистику.

Есть приложение, нет исходников, есть форма которая тормозит и есть ответ разработчика: "сам дурак", "у нас все работает". Вам очень повезет если после сбора статистики проблема уйдет и не появиться новой (новых). Система развивается и 100% появится новая проблема (этой ведь тоже когда то не было) и придется здесь народу отвечать на вопросы типа: "помогите, тормозит запрос исходников формы нет и в базе тоже ничего править не могу!!!".
Резюме: нужно строить диалог с разработчиком. Если он говорит что проблема из-за того что нет статистики, то как минимум должен гарантировать (хотя эту гарантию все равно нужно проверять :-) что система разрабатыватся под CBO и выдать совет как статистику собирать.

PS самое время начать документировать систему :-). Опишите регламент сбора статистики - когда убедитесь на практике в ее необходимости. Может разработчик еще чего подразумевал о чем вы не подозреваете - например ваш запрос тормозит из за выбоки по табличке которую нужно периодически чистить.
12 дек 06, 12:58    [3523642]     Ответить | Цитировать Сообщить модератору
 Re: И снова Statistics  [new]
Vladimirgs
Member

Откуда: Казань
Сообщений: 694
А вы не воспользовались моими запросами? для определения качества работы запросов? пример

SQL> select count(1), t.optimizer_mode from v$sql t group by t.optimizer_mode;

  COUNT(1) OPTIMIZER_MODE
---------- --------------
         4 ALL_ROWS
      3129 CHOOSE
         4 FIRST_ROWS
        79 RULE

SQL> select t.optimizer_mode, max(t.OPTIMIZER_COST), min(t.OPTIMIZER_COST), avg(t.OPTIMIZER_COST) from v$sql t group by t.optimizer_mode;

OPTIMIZER_MODE MAX(T.OPTIMIZER_COST) MIN(T.OPTIMIZER_COST) AVG(T.OPTIMIZER_COST)
-------------- --------------------- --------------------- ---------------------
ALL_ROWS                           2                     1                  1,25
CHOOSE                          7417                     0      50,2529581068116
FIRST_ROWS                        10                     8                  9,25
RULE                            3661                     0               106,375

SQL> select count(1) from v$sql t;

  COUNT(1)
----------
      3402

SQL> select count(1) from v$sql t where t.DISK_READS>0;

  COUNT(1)
----------
         89

SQL> 

Это конечно не свидетельство принципа построения, но попробуйте сделать это пред сбором статистики. Потом массово собрать по схеме приложения и через часок опять поглядеть.
Делать конечно на тестовой БД бы.
12 дек 06, 13:17    [3523828]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить