Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 141

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 135 136 137 138 139 140 < 141 > 142 143 144 145 146 147 .. 161 >> Следующая


Способы запуска отчетов

¦ Специальные запросы.

Когда отчет запускается специально вручную, высоки шансы, что инициатор запуска знает о действительной необходимости получения хотя бы части этого отчета. Также вполне вероятно, что его волнует, сколько времени придется ждать, пока отчет будет создан, и большое время выполнения отчета может принести бизнесу убытки. Когда отчет нужен пользователю как можно скорее, ему должен быть назначен высокий приоритет. Возможно даже, придется разбить его на параллельные процессы, которым, чтобы уложиться в поставленный срок, придется занять большую часть системных ресурсов. В противном случае полезно убедиться, что запросы не выполняются параллельно, таким образом, не снижая производительность процесса с высоким приоритетом. Кроме того, выполнение отчетов с низким приоритетом должно быть автоматически отложено до периода функционирования системы с низкой загрузкой. Этого обычно достаточно, чтобы исключить любое воздействие этих отчетов на производительность.

¦ Автоматические запросы.

Большая часть пакетной нагрузки на бизнес-системы создается автоматически в форме отчетов, для которых давным-давно было создано расписание запусков, и они выполняются автоматически каждые день, неделю, или через какой-то другой определенный период времени. Эти периодические пакетные процессы особенно коварны в плане создания нагрузки, так как о них так легко забыть или проигнорировать. Большинство заказчиков отчетов получают намного больше материалов, чем они когда-либо могут прочитать, даже если считать только материалы, созданные людьми, и не учитывать ужасающие автоматические отчеты с обширными наборами неинтересных чисел. Так или иначе, большинство людей, занятых в бизнесе, чувствуют себя несколько неудобно из-за невозможности прочитать и проанализировать огромное количество информации, поступающей на их адрес. Таким образом, вместо того, чтобы жаловаться, что они никогда не читают какой-то страшный отчет, получаемый ежедневно или еженедельно, и доказывать, что это лишь напрасная трата ресурсов, они продолжают смиренно молчать о своей постыдной неспособности совершить невозможное. (Я знаю, я тоже
Запросы, которые возвращают слишком много данных

287

так поступал. А вы?) Если вы хотите сократить частоту, с которой выдаются огромные отчеты, или удалить их совсем, не ждите, что адресаты отчета пожалуются, что они им не нужны!

Один из способов избавиться от отчетов — задать наводящий вопрос: «Мы подозреваем, что отчет больше не требуется, а как вы думаете?» Другая стратегия предлагает заявить: «Мы собираемся удалить этот отчет, который, по нашему мнению, больше не нужен, если только кто-либо из вас не сообщит, что ему этот отчет требуется. Если же вам нужен этот отчет, то хотите ли вы получать его с той же частотой, или можно выдавать его несколько реже?» Моя любимая стратегия — удалить из списка получателей отчета всех кроме себя и посмотреть, будет ли кто-нибудь жаловаться. Если кто-либо проявит себя, отправить ему копию и сохранить отчет, добавив этого человека обратно в список адресатов. Если же никто не пожалуется, то я просто удаляю запланированный отчет через безопасный промежуток времени. Конечно, я бы не рекомендовал делать это, не имея соответствующих полномочий. Для отчетов, получаемых по требованию, вы можете добиться тех же результатов, сделав файл недоступным и подождав жалоб.

Почему производительность пакетных запросов может стать проблемой

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

¦ Конечные пользователи ожидают получения результата.

Когда процесс требует, чтобы конечный пользователь запросил создание отчета, а следующая важная задача, которую пользователь может выполнить, требует вывода этого отчета, то время создания отчета является узким местом. Распараллеливание процесса создания отчета может стать одним из возможных решений, позволяя нескольким процессорам одновременно решать поставленную задачу. Также можно добиться этого на уровне сервера базы данных при помощи параллельных планов выполнения (которые за время моей работы никогда не оказывались полезными) или на уровне приложения, породив несколько прикладных процессов, одновременно решающих задачу, и в конце объединив результаты. Однако намного чаще решение заключается в удалении всего отчета или отдельных его частей. Это самый правильный способ, так как подобный процесс, представляющий собой узкое место в работе, редко требует, чтобы пользователь обработал огромный объем данных; есть лишь небольшая вероятность, что хотя бы несколько строчек отчета действительно нужны конечному пользователю.

¦ Отчет не успевает выполняться за установленный период.

Многим периодически выполняющимся процессам для работы отведено специальное временное окно, обычно в середине ночи или во время выходных. В оставшейся части главы описаны стратегии сокращения времени выполнения, позволяющие уложиться в данное временное окно. Однако чаще все-
Предыдущая << 1 .. 135 136 137 138 139 140 < 141 > 142 143 144 145 146 147 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100