Сегодня я хочу рассказать о своих приключениях, вызванных решением развернуть Oracle BI EE 11.1.1.5 на Oracle Linux.
Получил я для этих экспериментов в распоряжение такую машину....
Установка BI прошла без особых проблем (это, наверное, я так считаю, потому что занимался этим наш админ :-))
Мне оставалось только перенести RPD и Catalog с виндовой машины, на эту.
Задача достаточно тривиальная:
- копируем RPD
- копируем Catalog
- c помощью консоли http://localhost:7001/em указываем новый репозитарий и каталог (если распаковывали не в SampleAppLite, а куда-то рядом)
- перегружаем сервер
- выполняем операции по Refresh GUID (кстати, надо бы озаботиться и понять, как можно синхронизировать встроенный LDAP двух разных серверов Weblogic, чтобы не заниматься этой ерундой каждый раз при переносе Заказчику измененного RPD)
Все именно так и было.
После этих трех шагов я получил работающую систему, которая на первый взгляд полностью соответствовала исходной.
Но более детальное изучение dashboards привело меня в замешательство.
Вообщем проблема была в следующем:
1. Я имею основной Answer, в котором есть агрегированные показатели.
2. Этот answer отображает всякие русские наименования продуктов, товаров, услуг, отделов и прочей чепухи.
3. Далее, как и во всех аналитических системах, мы хотим детализироваться по продукту или подразделению. С помощью фильтров переходим на следующий детальный отчет и в нем получаем сообщение.
Я перепроверил ВСЕ, до чего дотянулись руки...:
- смотрел фильтры,
- смотрел детальный отчет,
- смотрел nqquery.log (по логу в сервер баз данных уходил нормальный правильный запрос, в ответ на который возвращалось 0 строк).
После всех этих проверок у меня мелькнула мысль о КОДИРОВКЕ, но дальнейшего развития она не получила, т.к. в результатах answer я прекрасно вижу все наименования по-русски.
Быстро решить проблему не удалось. Пришлось создавать простейшую тестовую ситуацию, чтобы исключить возможные приобретенные проблемы от переноса репозитария и каталога с Win на Linux.
Пришлось делать следующее:
1. Восстановить репозитарий и каталог на те примеры, которые были созданы в ходе установки.
2. Созать в репозитарии connection к базе данных, работа с которой вызывала у меня проблемы.
3. Создаю простейший answer на основе прямого запроса к базе.
4. Получаю предсказуемые результаты.
5. Меняю English на Русский.. И не получаю ничего...
На экране выглядит это "ничего" так -
6. Я решаю убрать условие и вижу, что вместо слова 'РУССКИЙ', сервер BI показывает мне '???????'.
Таким образом, все-таки где-то проблемы с кодировкой.
При этом, что меня больше всего поразило, что эти проблемы возникают только при передаче данных от сервера приложений в сервер базы данных. Если я просто считываю данные из базы данных, то кирилица отображается без каких-либо проблем.
В итоге, вылечилось все выполнением следующих операций в терминале сервера LINUX.
opmnctl stopall
NLS_LANG=RUSSIAN_CIS.UTF-8
export NLS_LANG
echo $NLS_LANG
opmnctl startall
Получил я для этих экспериментов в распоряжение такую машину....
Установка BI прошла без особых проблем (это, наверное, я так считаю, потому что занимался этим наш админ :-))
Мне оставалось только перенести RPD и Catalog с виндовой машины, на эту.
Задача достаточно тривиальная:
- копируем RPD
- копируем Catalog
- c помощью консоли http://localhost:7001/em указываем новый репозитарий и каталог (если распаковывали не в SampleAppLite, а куда-то рядом)
- перегружаем сервер
- выполняем операции по Refresh GUID (кстати, надо бы озаботиться и понять, как можно синхронизировать встроенный LDAP двух разных серверов Weblogic, чтобы не заниматься этой ерундой каждый раз при переносе Заказчику измененного RPD)
Все именно так и было.
После этих трех шагов я получил работающую систему, которая на первый взгляд полностью соответствовала исходной.
Но более детальное изучение dashboards привело меня в замешательство.
Вообщем проблема была в следующем:
1. Я имею основной Answer, в котором есть агрегированные показатели.
2. Этот answer отображает всякие русские наименования продуктов, товаров, услуг, отделов и прочей чепухи.
3. Далее, как и во всех аналитических системах, мы хотим детализироваться по продукту или подразделению. С помощью фильтров переходим на следующий детальный отчет и в нем получаем сообщение.
- смотрел фильтры,
- смотрел детальный отчет,
- смотрел nqquery.log (по логу в сервер баз данных уходил нормальный правильный запрос, в ответ на который возвращалось 0 строк).
После всех этих проверок у меня мелькнула мысль о КОДИРОВКЕ, но дальнейшего развития она не получила, т.к. в результатах answer я прекрасно вижу все наименования по-русски.
Быстро решить проблему не удалось. Пришлось создавать простейшую тестовую ситуацию, чтобы исключить возможные приобретенные проблемы от переноса репозитария и каталога с Win на Linux.
Пришлось делать следующее:
1. Восстановить репозитарий и каталог на те примеры, которые были созданы в ходе установки.
2. Созать в репозитарии connection к базе данных, работа с которой вызывала у меня проблемы.
3. Создаю простейший answer на основе прямого запроса к базе.
На экране выглядит это "ничего" так -
Таким образом, все-таки где-то проблемы с кодировкой.
При этом, что меня больше всего поразило, что эти проблемы возникают только при передаче данных от сервера приложений в сервер базы данных. Если я просто считываю данные из базы данных, то кирилица отображается без каких-либо проблем.
В итоге, вылечилось все выполнением следующих операций в терминале сервера LINUX.
opmnctl stopall
NLS_LANG=RUSSIAN_CIS.UTF-8
export NLS_LANG
echo $NLS_LANG
opmnctl startall
Комментариев нет:
Отправить комментарий