Текущее время: Вс, июл 27 2025, 06:14

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 56 ]  На страницу Пред.  1, 2, 3, 4
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Пт, авг 31 2007, 11:20 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Dzed Maroz написал:
ABC написал(а):
mandt - добро


Обоснуй :D


С точки зрения использования поля madnt в индексах.

Факты:
1.В запросе к БД со стороны SAP ВСЕГДА присутствует поле mandt, за исключением случаев, когда особо умные разработчики делают SELECT ... CLIENT SPECIFIED без использования условия по манданту.

Отсюда следует, что любой оптимизатор в первую очередь будет рассматривать индексы, в которых есть поле mandt, при прочих равнх условиях.

2.Первичный индекс ВСЕГДА имеет поле mandt.

Следовательно, и все остальные индексы, в которых содержатся поля из первичного индекса, должны содержать поле mandt.

ЗЫ: Естественно, рассматриваются только манданто-зависимые таблицы ;)

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, авг 31 2007, 11:54 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Ср, июн 13 2007, 16:36
Сообщения: 585
Откуда: Belarus
Пол: Мужской
Удав написал(а):
С точки зрения использования поля madnt в индексах.
Факты:
1.В запросе к БД со стороны SAP ВСЕГДА присутствует поле mandt, за исключением случаев, когда особо умные разработчики делают SELECT ... CLIENT SPECIFIED без использования условия по манданту.

Отсюда следует, что любой оптимизатор в первую очередь будет рассматривать индексы, в которых есть поле mandt, при прочих равнх условиях.

2.Первичный индекс ВСЕГДА имеет поле mandt.

Следовательно, и все остальные индексы, в которых содержатся поля из первичного индекса, должны содержать поле mandt.

ЗЫ: Естественно, рассматриваются только манданто-зависимые таблицы ;)

1. Если я правильно понял из документации, то SAP считает индексы с mandt уникальными, то есть, как ты назвал - первичными.
2. Остальные индексы - неуникальные и имеют меньший приоритет перед уникальными.
3. Предлагаю вернуться к началу топика. Таблицу T001 я взял от балды и просто так совпало, что там в ключе есть mandt. Не совсем удачный пример получился, спор возник про этот самый mandt :)
Возьмём индекс без него. Вот смотрю у себя в системе на MARD. Помимо уникального индекса (mandt+matnr+werks+lgort) есть ещё один - werks+lgort.
При запросе
Code:
select * from mard where werks = 'XXX'

оптимизатор говорит - Table Access Full
Но при запросе
Code:
select * from mard where werks = 'XXX' and lgort = '1111'

оптимизатор говорит Table Access By Index
Возникает два вопроса:
1. Оптимизатор мне правильно показывает, что индекс был использован только во втором случае ?
2. Если да, то почему он не был использован в первом ?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, авг 31 2007, 12:23 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Dzed Maroz написал:
1. Если я правильно понял из документации, то SAP считает индексы с mandt уникальными, то есть, как ты назвал - первичными.
2. Остальные индексы - неуникальные и имеют меньший приоритет перед уникальными.

Ну не совсем так. Первичный индекс всегда один.
И я говорил
Удав написал(а):
оптимизатор в первую очередь будет рассматривать индексы, в которых есть поле mandt, при прочих равных условиях.


Dzed Maroz написал:
Вот смотрю у себя в системе на MARD. Помимо уникального индекса (mandt+matnr+werks+lgort) есть ещё один - werks+lgort.
При запросе
Code:
select * from mard where werks = 'XXX'

оптимизатор говорит - Table Access Full
Но при запросе
Code:
select * from mard where werks = 'XXX' and lgort = '1111'

оптимизатор говорит Table Access By Index

А какой именно индекс взялся?
Первичный или werks+lgort? :D

Оптимизатор ведь помимо полей еще анализирует их селективность.
У поля matnr большая селективность, т.е. включение его в where резко снижает область поиска.
В условии оно не задано, поэтому может выбраться индекс werks+lgort, несмотря на то что в первичном индексе полей, указанных в where больше.

1.select * from mard where werks = 'XXX'
Здесь получается, что в where участвуют 2 поля: mandt и werks.
Поэтому выбирается первичный индекс.
Далее, ввиду низкой селетивности условия и не очень большого объема таблицы оптимизатор решает, что выгоднее будет один раз полностью поместить таблицу MARD в кэш БД, чтобы остальные запросы к MARD выполнялись быстрее.

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, авг 31 2007, 12:43 
Старший специалист
Старший специалист
Аватара пользователя

Зарегистрирован:
Вс, окт 17 2004, 14:20
Сообщения: 326
Откуда: Москва
2 Dzed Maroz Советую почитать теорию - что такое уникальные, неуникальные индексы.
Так же неплохо разобраться с тем что же такое мандант.
А то чувствуется, что каша в голове...


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, авг 31 2007, 13:39 
Ассистент
Ассистент

Зарегистрирован:
Пн, окт 11 2004, 12:15
Сообщения: 46
Сорри , небольшое отступление от темы.

С установкой некоторых пакэджей, некоторые таблицы перестают реагировать на индексы. Ходил к базисникам так и есть - внутри сап этим таблицам присваивает статус типа без индексов (причем если базисники меняли этот статус руками - то САП ругался.., хотя все работало).
Поэтому приходилось руками хинты к селектам прикручивать.

А вообще с индексами много чего бывает , что иногда волосы шевелятся)), и как правило всегда находится причина.


2 дед мороз.
Разберись с таблицами и индексами и уж тем более что такое клиент(Mandt)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, авг 31 2007, 15:07 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Ср, июн 13 2007, 16:36
Сообщения: 585
Откуда: Belarus
Пол: Мужской
Эх, пятница ......
Разобрался и с таблицами, и с индексами :)
Но показания оптимизатора так и остались для меня загадкой .... :?

Всех с пятницей и завтрашней осенью :wink:
\me ушёл начинать начинать пить вотку ....


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, сен 11 2007, 22:17 
Президент
Президент

Зарегистрирован:
Пт, апр 28 2006, 22:39
Сообщения: 2514
Откуда: North Taxolina, USA
Пол: Женский
Разобрались - оказалось виноват был SELECT, который вызывался в ФМ IN UPDATE TASK. Он содержал FOR ALL ENTRIES IN itab и, есессна, проверить, а не пустая ли itab, никто не удосужился. (Честно говоря, до сих пор не понимаю почему это так бредово работает в SAP, но это отдельная тема.)

Мораль - надо самой пользоваться поиском 'where used', а не полагаться на утверждения "знатоков", что вот оно, единственное место, где эта таблица используется. Очень стыдно - запарилась совсем. :oops: И еще ST04 очень помогает, но у нас почему-то допуск туда дают неохотно.

Огромное спасибо всем ответившим, по ходу дела узнала очень много нового для себя, чесс слово.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re:
СообщениеДобавлено: Пн, май 04 2009, 17:02 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Ср, июл 19 2006, 09:40
Сообщения: 57
Откуда: С гор
ABC написал(а):
Jelena написала:
quote="ABC"
2. Случаем не добавляли в таблицу одно из полей, по которому делается выборка, после того, как там уже были записи? Если да, то не забыли сделать адаптацию таблицы в утилите базы данных?/quote
Вообще-то да, поле добавляли, но адаптация была сделана.

Может в продуктиве забыли сделать? Кстати, что значит "адаптация была сделана"? После "Активировать и адаптировать" в утилите БД запускали "Дополнительная информация"->"Инициировать преобразование" ("Extras"->"Force Conversion")?


Подскажите, что за утилита такая с помощью которой активируются вновь добавленные в отчете (SAP Query) поля после переноса в продуктив.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SELECT с индексом читает всю таблицу
СообщениеДобавлено: Сб, май 16 2009, 16:44 
Модератор
Модератор

Зарегистрирован:
Пт, ноя 12 2004, 11:40
Сообщения: 542
Откуда: Москва
Пол: Мужской
Привет всем, всё не читал :))) но может прям в запросе hint'ом подсказать oracl'овому оптимизатору какой индекс использовать?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SELECT с индексом читает всю таблицу
СообщениеДобавлено: Сб, май 16 2009, 21:38 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Пн, окт 11 2004, 20:32
Сообщения: 2470
Пол: Мужской
Ich Will написал:
Привет всем, всё не читал :))) но может прям в запросе hint'ом подсказать oracl'овому оптимизатору какой индекс использовать?

привет, канешна можно
только вот вы несколько запоздали с советом ;)

_________________
- Может ли настоящий мастер кунг-фу получить по морде?
- Настоящий мастер может все!


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SELECT с индексом читает всю таблицу
СообщениеДобавлено: Пн, май 18 2009, 12:00 
Менеджер
Менеджер

Зарегистрирован:
Вт, авг 17 2004, 13:14
Сообщения: 664
Откуда: Москва
Пол: Мужской
2 года теме :)
Там же пару раз говорили: необходимо собрать статистику. Я так понял, что никто не обратил на это внимание, а зря! У Oracle есть такая фича, если статистика не собрана или устарела, то индекс не используется.


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 56 ]  На страницу Пред.  1, 2, 3, 4

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot]


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB