#runtime #cognos-11
Вопрос:
У меня есть ежедневный запланированный отчет COGNOS, созданный кем-то другим несколько месяцев назад. Этот разработчик покинул компанию более месяца назад. Из того, что мне сказали, этот отчет прошел нормально. Затем за неделю до того, как разработчик покинул компанию, запуск стал занимать все больше и больше времени. Теперь это занимает 11-12 часов. Для отчета нет документации, в которой указывались бы любые возможные изменения, внесенные разработчиком, которые могли бы привести к этому. И как совсем недавний новый сотрудник; До сих пор я не знаю о каких-либо изменениях БД, которые могли вызвать возникновение проблемы. Я надеялся, что кто-то более опытный сможет указать мне правильное направление.
Нужно ли мне исследовать изменения в базе данных? Может ли это быть проблемой с кэшем? Может быть, проблема с разрешениями или просто проблема с созданным расписанием?
Дайте мне знать, какая дополнительная информация была бы полезна.
Комментарии:
1. Можете ли вы описать, что вы пробовали до сих пор? Какой уровень/область может быть причиной проблемы (сеть, модель, sql и т. Д.)? Какая база данных? Какая оптимизация была проведена (пути доступа, EVI, двоичный радиус и т.д.)? Можем ли мы увидеть инструкцию SQL?
2. Я еще не пробовал ничего примечательного. Я очень плохо разбираюсь в том, что делаю. Я еще не видел базу данных и даже не был знаком с процессом создания пакета. Я использовал для этого фреймворк-менеджер много лет назад, но, знаете, все это кажется совсем другим. Так что я в основном пытался провести исследование. Я не ожидаю получить однозначное решение моей проблемы прямо сейчас. Я не думаю, что у меня достаточно информации, чтобы предоставить ее для этого. Я просто надеялся получить совет от эксперта, который мог бы, по крайней мере, помочь направить мои исследования в правильном направлении. Извините, у меня нет запрошенной вами информации.
3. Нп, я дал несколько предложений ниже. Попробуйте и посмотрите, поможет ли это. Дайте мне знать, и мы во всем разберемся
Ответ №1:
- Проверьте, не связана ли низкая производительность с определенным элементом данных
Начните с упрощенной версии отчета
Например, если у вас есть отчет с 10 столбцами
Сократите отчет до 3 столбцов и сравните производительность.
Затем добавьте обратно один элемент данных/столбец и повторно проверьте, если вы заметили разницу, связанную с конкретным элементом данных, изучите изменения в инструкции SQL. Ищите внешние соединения или, возможно, сложные выражения с функциями, которые могут повлиять на производительность
- Ищите логическую ловушку
Возможно, вы наблюдаете логическую ловушку, подобную пропасти данных, в которой вы получаете декартово произведение результатов, потому что запрос представляет собой отношение «многие ко многим»
- Проверьте систему источников данных
Возможно, время суток, в которое выполняется процесс, сейчас находится в конфликте с другим конкурирующим процессом, который имеет приоритет/все ресурсы, чтобы помочь проверить это, попробуйте запустить анализ в непиковое время
- Изоляция/эскалация блокировки курсора Проверьте свои настройки, чтобы узнать, каков уровень изоляции курсора.Будьте осторожны, не меняйте это значение случайно, так как это повлияет на доступ к источнику данных. Если у вас есть тестовая система, попробуйте выполнить незафиксированное чтение (или грязное чтение), чтобы избежать проблем с блокировкой. Если другой пользователь поддерживает или обновляет таблицы данных/операций, это может повлиять на время отклика SQL
Комментарии:
1. Спасибо вам за ответ. Я рассмотрю предлагаемые действия и дам вам знать, что я найду. Я могу сказать, что я действительно пытался искать конкретные элементы, которые снижали производительность. Я проверил табличные данные для каждого из 18 запросов. Просто чтобы посмотреть, как долго они продержатся. Из 18 запросов 6 завершились за несколько секунд. Остальные 12 заняли слишком много времени, чтобы закончить. Поэтому я создал пустой отчет и начал воссоздавать один из этих запросов. Даже с одним элементом данных выполнение запроса заняло слишком много времени. Что наводит меня на мысль, что проблема, скорее всего, выходит за рамки отчета.
2. Если вы можете поделиться SQL или даже psuedo-кодом инструкции. Возможно, вам удастся обнаружить проблему или предложить альтернативу SQL, которую вы можете попробовать
Ответ №2:
Какой тип источника данных использовался для этого отчета? Многомерные или реляционные? Какой режим был использован — классический или динамический? Рассылает ли этот отчет информацию разным пользователям по электронной почте? Возможно, были использованы разрывные и мастер-детали, которые часто снижают производительность.