В данной статье я хочу рассказать о моем опыте развертывания и использования SSRS 2008 в крупной компании. Процесс настройки и развертывания был 3 года назад, а сама система Reporting Services используется организацией уже 4 года.
Изначально ситуация была такая – фирма купила Sharepoint 2010 и хотела, чтобы на нем были отчеты, которые могли бы просматривать сотрудники предприятия. Данные для отчетов хранились в Oracle. Выбор был сделан в пользу Reporting Services 2008. Так как SSRS 2008 интегрирован в Sharepoint и у предприятия был в наличие MS SQL Server 2008, со всеми его компонентами. Параллельно принимались попытки реализовать отчеты на Oracle BI, но по неизвестным мне причинам, эти разработки прекратились, после того как массово получилось внедрить SSRS 2008.
При работе с Reporting’ом возник ряд проблем, о которых я хочу рассказать ниже:
Первая проблема, с которой пришлось столкнуться – это зависание при возрастании числа запросов от пользователей. Эта проблема чуть не сгубила всю затею, т.к. сервер переставал отвечать на запросы, и его приходилось перегружать. А так как пользователей много, то он практически сразу же после перезагрузки ложился опять.
Проблема оказалась в пуле коннекций к базе. Если его отключить в параметрах соединения с базой, то всё работало стабильно, но медленно. Это, в свою очередь, сильно не устраивало пользователей. Так же можно было изменить значение ConnectTimeout, но привело к тому, что с увеличением нагрузки на сервер, отчеты, которые раньше всегда выполнялись стали отваливаться по истечении времени ожидания. Проблему решили, установив одинаковые значения max pool size и min pool size. На данный момент оба эти значения равны 23.
Вторая проблема состояла в том, что появились отчеты, которые выполнялись очень долго.
Решением этой проблемы было выкручивание двух таймаутов — SessionAccessTimeout и SessionTimeout. Их можно выставить с помошью SQL скрипта в базе SSRS:
До какого-то момента это помогает. Но рано или поздно появляются такие отчеты, которые все равно приводят к timeout expired. Грузить же их в offline было проблематично, т.к. доступ к данным в отчете зависел от учетной записи пользователя, а массив загруженных данных отличался существенно, в зависимости от разрешений пользователя. Текущее решение заключается в специальной утилите, разработанной мной, для выгрузки отчетов, которые очень долго формируются из базы.
Так же ряд отчетов, с не очень большим временем выполнения, падали с ошибкой:
“Request timed out” или по-русски пишет “Превышен интервал ожидания для запроса”. Эта проблема связанна уже с размером отчета. Для исправления этой ошибки необходимо совершить три действия:
В процессе внедрения, выяснилось, что практически все пользователи в организации предпочитают работать в Excel, а не с Web-формой отчета. Поэтому они каждый раз выгружали отчет в формате Excel к себе на компьютер и далее работали с ним. Когда размер отчета становился слишком большим, то SSRS не мог его выгрузить. Он зависал с сообщением об ошибке.
Возможно, проблема тут была не в SSRS 2008, а в расширении от фирмы Aspose. Это расширение было установлено для поддержки формата xlsx, так как Reporting Services 2008 не поддерживали данный формат. Данная проблема возникала только при экспорте в Excel (*.xlsx), при экспорте в csv формат подобного не наблюдалось. В итоге, задача была решена с помощью отдельной утилиты, благо таких отчетов оказалось не так много.
Стоит отметить так же пару моментов при разработке отчетов под SSRS 2008:
Первый момент – это ошибка при делении на 0. Если, например, вам надо вывести значения в колонке, которое является результатом деления одного поля выборки на другое, то выражение
Его можно прописать в выводимой колонке вместо iif.
Второй момент – это передача в запрос multiple values параметров. В случае если тип параметров числовой, то проблем не возникнет. Но если надо передать строковые значения, то так же необходимо будет внести изменения в поле “Значения параметра”. Надо вместо
Ещё при работе в Reporting Services c БД Oracle следует все числовые поля явно округлять непосредственно в SQL запросе, т.к. у этих систем различная точность.
Помимо вышеперечисленных проблем и нюансов так же периодически возникала проблема с установкой и запуском SQL Report Builder’а. Эта проблема связанна с клиентской машиной, на котором его запускали, и решается она путем индивидуального подхода каждой такой машине.
Что касается установки SSRS 2008, то изначально он устанавливался вместе с базой данных Shrepoint 2010, но позже, когда разжились дополнительными серверами, SSRS был установлен на отдельной машине.
На данный момент организация приобрела Sarepoint 2013 и SSRS 2012, но мое непосредственное руководство не проявляет интереса к переходу на новые версии, мотивируя это стабильностью старых.
При работе с большими объемами данных, там, где это возможно, используется Analysis Services. В сравнении с Analysis Services, основное удобство SSRS, в том что отчет может создавать программист баз данных, на основе уже написанного им запроса. Создание же сущностей на Analysis Services требует больших усилий и времени.
Надеюсь, что данная информация будет полезной и либо поможет в эксплуатации SSRS 2008, либо повлияет на принятие решения об эксплуатации данного продукта.
Изначально ситуация была такая – фирма купила Sharepoint 2010 и хотела, чтобы на нем были отчеты, которые могли бы просматривать сотрудники предприятия. Данные для отчетов хранились в Oracle. Выбор был сделан в пользу Reporting Services 2008. Так как SSRS 2008 интегрирован в Sharepoint и у предприятия был в наличие MS SQL Server 2008, со всеми его компонентами. Параллельно принимались попытки реализовать отчеты на Oracle BI, но по неизвестным мне причинам, эти разработки прекратились, после того как массово получилось внедрить SSRS 2008.
При работе с Reporting’ом возник ряд проблем, о которых я хочу рассказать ниже:
Первая проблема, с которой пришлось столкнуться – это зависание при возрастании числа запросов от пользователей. Эта проблема чуть не сгубила всю затею, т.к. сервер переставал отвечать на запросы, и его приходилось перегружать. А так как пользователей много, то он практически сразу же после перезагрузки ложился опять.
Проблема оказалась в пуле коннекций к базе. Если его отключить в параметрах соединения с базой, то всё работало стабильно, но медленно. Это, в свою очередь, сильно не устраивало пользователей. Так же можно было изменить значение ConnectTimeout, но привело к тому, что с увеличением нагрузки на сервер, отчеты, которые раньше всегда выполнялись стали отваливаться по истечении времени ожидания. Проблему решили, установив одинаковые значения max pool size и min pool size. На данный момент оба эти значения равны 23.
Вторая проблема состояла в том, что появились отчеты, которые выполнялись очень долго.
Решением этой проблемы было выкручивание двух таймаутов — SessionAccessTimeout и SessionTimeout. Их можно выставить с помошью SQL скрипта в базе SSRS:
SetConfigurationInfo 'SessionAccessTimeout', '7200'
SetConfigurationInfo 'SessionTimeout', '7200'
До какого-то момента это помогает. Но рано или поздно появляются такие отчеты, которые все равно приводят к timeout expired. Грузить же их в offline было проблематично, т.к. доступ к данным в отчете зависел от учетной записи пользователя, а массив загруженных данных отличался существенно, в зависимости от разрешений пользователя. Текущее решение заключается в специальной утилите, разработанной мной, для выгрузки отчетов, которые очень долго формируются из базы.
Так же ряд отчетов, с не очень большим временем выполнения, падали с ошибкой:
“Request timed out” или по-русски пишет “Превышен интервал ожидания для запроса”. Эта проблема связанна уже с размером отчета. Для исправления этой ошибки необходимо совершить три действия:
- Во-первых, надо изменить значения executionTimeout и maxRequestLength Sharepoint’а. Это делается в файле web.config, путь к которому Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\web.config
Вместо
Надо написать что-то подобное:<httpRuntime executionTimeout="360" />
<httpRuntime executionTimeout="999999" maxRequestLength="2097151" /> - Во-вторых, надо увеличить эти же значения в web.config виртуальной директории Sharepoint
Inetpub\wwwroot\wss\VirtualDirectories\VirtualDirectoryFolder\ web.config - И, в-третьих, последний шаг – это зайти в Центр администрирования SharePoint и там, выбрав Reporting установить необходимое значение в параметре “Максимальный объем отправляемых данных”.
В процессе внедрения, выяснилось, что практически все пользователи в организации предпочитают работать в Excel, а не с Web-формой отчета. Поэтому они каждый раз выгружали отчет в формате Excel к себе на компьютер и далее работали с ним. Когда размер отчета становился слишком большим, то SSRS не мог его выгрузить. Он зависал с сообщением об ошибке.
Возможно, проблема тут была не в SSRS 2008, а в расширении от фирмы Aspose. Это расширение было установлено для поддержки формата xlsx, так как Reporting Services 2008 не поддерживали данный формат. Данная проблема возникала только при экспорте в Excel (*.xlsx), при экспорте в csv формат подобного не наблюдалось. В итоге, задача была решена с помощью отдельной утилиты, благо таких отчетов оказалось не так много.
Стоит отметить так же пару моментов при разработке отчетов под SSRS 2008:
Первый момент – это ошибка при делении на 0. Если, например, вам надо вывести значения в колонке, которое является результатом деления одного поля выборки на другое, то выражение
Iif(exp2 = 0, 0, exp1/exp2 )
Public Function DivM(ByVal exp1, ByVal exp2)
if exp2 = 0 Then
DivM = 0
Else DivM = exp1/exp2
End If
End Function
Его можно прописать в выводимой колонке вместо iif.
Второй момент – это передача в запрос multiple values параметров. В случае если тип параметров числовой, то проблем не возникнет. Но если надо передать строковые значения, то так же необходимо будет внести изменения в поле “Значения параметра”. Надо вместо
Parameters!МойПараметр.Valuesplit(join(Parameters!МойПараметр.Value,”,”),”,”)Ещё при работе в Reporting Services c БД Oracle следует все числовые поля явно округлять непосредственно в SQL запросе, т.к. у этих систем различная точность.
Помимо вышеперечисленных проблем и нюансов так же периодически возникала проблема с установкой и запуском SQL Report Builder’а. Эта проблема связанна с клиентской машиной, на котором его запускали, и решается она путем индивидуального подхода каждой такой машине.
Что касается установки SSRS 2008, то изначально он устанавливался вместе с базой данных Shrepoint 2010, но позже, когда разжились дополнительными серверами, SSRS был установлен на отдельной машине.
На данный момент организация приобрела Sarepoint 2013 и SSRS 2012, но мое непосредственное руководство не проявляет интереса к переходу на новые версии, мотивируя это стабильностью старых.
При работе с большими объемами данных, там, где это возможно, используется Analysis Services. В сравнении с Analysis Services, основное удобство SSRS, в том что отчет может создавать программист баз данных, на основе уже написанного им запроса. Создание же сущностей на Analysis Services требует больших усилий и времени.
Надеюсь, что данная информация будет полезной и либо поможет в эксплуатации SSRS 2008, либо повлияет на принятие решения об эксплуатации данного продукта.