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

Иногда невозможно заранее угадать, насколько селективным будет поиск, если не выполнить его. Селективность часто зависит от конкретных данных приложения. Например, с большой вероятностью приложение вернет больше соответствий для фамилии Smith , чем для Kmetec , но вы совершенно не хотите жестко кодировать список частот, с которыми встречаются различные имена, в приложении. В таких случаях вам нужен способ убедиться, что список слишком длинный, при этом не тратясь на считывание полного списка. Решение состоит из нескольких шагов.

1. Определите максимальную длину списка, который можно возвратить без ошибки. Чтобы нам бьшо удобнее рассуждать, предположим, что максимальная длина равна 500.

2. В обращении к базе данных запросите на одну строку больше, чем выбранная максимальная длина (501 строка для нашего примера).

3. Заранее примите меры, чтобы план вьшолнения запроса бьш надежным и возвращал строки, используя вложенные циклы, чтобы до того, как вернуть первую партию, состоящую из 501 строки, не было необходимости предварительно хэшировать, сортировать или иным способом хранить весь набор строк.

4. Сделайте так, чтобы запрос возвращал данные не проводя сортировку, чтобы базе данных не нужно было считывать все строки перед тем, как вернуть первые результаты.

5. Отсортируйте результаты, как необходимо, на уровне приложения, если результат не вызвал ошибку, перейдя за установленный порог (501 строка для нашего примера).

6. Отмените запрос и возвратите сообщение об ошибке с просьбой указать более селективный критерий поиска, если количество строк достигло максимального значения (501 строка для нашего примера).

На моем прежнем месте работы в качестве настройщика производительности, в TenFold Corporation, эта техника оказалась так полезна, что мы внедрили ее в платформу приложения EnterpriseTenFold, добавив возможность изменять максимальное количество строк.

Итак, предотвращайте объемные оперативные запросы при помощи трехстороннего подхода.

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

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

Запускайте потенциально объемные запросы так, чтобы получать первые строки быстро, и возвращайте сообщение об ошибке, как только количество возвращенных строк перейдет выбранный порог.

Объемные пакетные отчеты

Медленные действия приложений так неприятны для пользователей, что они не остаются неисправленными. Испытавшие их на себе конечные пользователи либо меняют свое поведение, либо достаточно громко жалуются, чтобы проблема была вскоре решена. Пакетная загрузка может нести скрытую опасность, так как зачастую проблемы с пакетной производительностью остаются незамеченными, создавая огромную нагрузку и понижая пропускную способность системы, но никак не проявляя себя в явном виде. Когда общая загрузка слишком высока, замедляются все составляющие приложения, но пакетные процессы, потребляющие слишком много системных ресурсов, могут все также работать достаточно хорошо, чтобы оставаться незамеченными, особенно если это низкоприоритетные процессы, завершения которых никто не ждет с нетерпением. Пергюдиче-ские пакетные процессы с автоматическим расписанием особенно опасны. Они могут запускаться намного чаще, чем это необходимо, и никто этого не заметит. Может отпасть необходимость использовать их так же часто, как и раньше, или они могут стать вовсе ненужными, но все так же выполняться, незаметно ухудшая работу системы.

В целом есть несколько вопросов относительно больших пакетных отчетов, ответив на которые, можно выбрать решение проблемы производительности.

Какова причина создания отчета?

Как инициируется создание отчета?

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

Информацию какого типа читатель извлекает из отчета?

Ответы на все эти вопросы влияют на получение лучшего ответа на последний вопрос - как повысить производительность отчета?

Причины создания больших отчетов

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

У отчета множество читателей, каждый из которых заинтересован в разных поднаборах данных.

Никто не читает отчет от корки до корки, но любая данная часть отчета может быть интересна, по меньшей мере, одному из читателей. Цели, которые преследуют такие отчеты, лучше достигать при помощи нескольких небольших отчетов. Если необходимо, они могут выполняться параллельно, поэтому системе становится проще считать все необходимые данные быстрее. Также каждый отчет может выполняться настолько часто, как это нужно

только его читателям, не заставляя всех пользователей читать общие данные.

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

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

Используется только поднабор данных запроса.

В этом случае решение очевидно и чрезвычайно выгодно. Просто исключите из запроса и отчета те строки, которые никогда не используются. Там, где отчет выводит меньше строк, чем возвращает запрос, добавьте фильтры, чтобы пропустить только необходимые отчету строки. Если вы сокращаете сам отчет, добавьте фильтры в запросы, обслуживающие сокращенный отчет, и настройте запросы так, чтобы они никогда не затрагивали ненужные данные. Особый случай, когда требуется лишь поднабор данных, возникает, когда конечный пользователь запрашивает только суммарную информацию (то есть агрегации) из отчета, содержащего и детали, и агрегатные данные. В этом случае исключите детали и из отчета, и из запросов к базе данных, и обратитесь к разделу Агрегация множества деталей за дальнейшими решениями.

Отчет необходим только по правовым причинам, а не потому, что кто-либо когда-либо прочтет его.

Такое оправдание существования отчета вызывает несколько вопросов. Действительно ли правовые нормы все так же требуют его создания, или же требования давно упразднены, а вы вьщаете отчет лишь по привычке? Действительно ли он нужен так часто, как вы его создаете? Если огромные отчеты создаются изредка, то маловероятно, что они превратятся в проблему производительности или пропускной способности, поэтому крайне необходимо вьщавать их как можно реже, если не можете совсем избавиться от отчетов. Действительно ли закон требует данных в форме этого отчета, или же будет достаточно предоставлять доступ к данным в иной форме? Часто требования к сохранению данных не указывают, в какой форме они должны храниться. Сама база данных или ее резервные копии могут вполне удовлетворять требованиям без прикладных отчетов. Если отчет необходим только по правовым причинам, то его, вероятно, можно выполнять в свободные часы, когда нагрузка не представляет проблемы.