ISA 2004 Std + SQL Server 2000 SP4 Логгирование - Компьютерный форум OSzone.net

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Программирование и базы данных (http://forum.oszone.net/forumdisplay.php?f=21)

- - ISA 2004 Std + SQL Server 2000 SP4 Логгирование (http://forum.oszone.net/showthread.php?t=145804)

ISA 2004 Std + SQL Server 2000 SP4 Логгирование

Имеем логи с вышеуказанной системы. В таблицах Webproxylog - 350 000 записей, в Firewalllog - 4 000 000. Если писать простой запрос вида

Код:

select count(1) from firewalllog

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

Код:

select Destination, sum(bytesrecvd) from firewalllog where rtrim(destinationNetwork)='External' and bytesrecvd <>0.0

and rtrim(OriginalClientIP) = '172.28.95.1' and (logdate between '2009-07-01' and '2009-07-21')

group by Destination order by sum(bytesrecvd)

Запрос элементарный, однако после 45 минут ожидания результат не появился.
В чем проблема? Если я пишу запрос типа

Код:

select Destination from firewalllog where rtrim(destinationNetwork)='External'

То результат мгновенен. Т.е. индексы работают.

В чем может быть причина такой медленной обработки данных?

а logdate тоже проиндексирован? rtrim обязателен?

Цитата:

Цитата Busla

logdate тоже проиндексирован? rtrim обязателен? »

Да, проиндексирован. rtrim обязателен в том плане, что иногда
OriginalClientIP = '172.28.95.1' не сработает, т.к. в OriginalClientIP могут быть последующие пробелы.

Delirium, я больше всего грешу на rtrim и тут ничего не поделаешь - результаты выполнения функций не индексируются. Можно "помухлевать" с триггерами, полями по умолчанию и в результате заставить SQL сразу писать правильный лог - без хвостовых пробелов. IP наверное будет правильнее вообще в виде числа хранить.

Busla, я могу вообще исключить rtrim и эту проверку, я просто пример привел. С триггерами и прочим мухлевать - не выход. IP будет храниться только так, т.к. это стандартное логгирование ISA Server, если поменять структуру базы, будет исключение. У меня раньше миллионы записей лопатил быстро(на других серверах) в других организациях. Здесь же такая загвоздка.

Тогда только стандартные решения: посмотреть план выполнения; включить трассировку, дождаться выполнения запроса (оставить на ночь), посмотреть какую оптимизацию предложит встроенный анализатор.

Оптимизатор предложил мне только поля logdate и logtime индексировать, 99% времени в плане выполнения - select....
У меня есть одно подозрение - у данной БД стоит модель логов - SIMPLE. При попытке индексирования вышеуказанных полей выдается предупреждение "Log file is full". Возможно, необходимо изменить уровень логгирования на Medium или Full, и тогда все заработает. На след. неделе проверю.

сомнительно - уровень логирования задаёт регулярность очистки логов simple - сразу, full - только принудительно
а SQL Server настоящий, не MSDE? Места на разделе хватает? Автоприращение лог-файла включено?