Основы Oracle Fusion Middleware High Availability

Обеспечение высокой доступности это одна из ключевых требований в любом промышленном внедрении. Внедрение систем высокой доступности обеспечивает минимизацию времени простоя системы и максимизацию времени доступности.
Простой системы бывает двух видов:

• Планируемый – запланированные административные операции;
• Непланируемый – любой незапланированный сбой.

Оба типа простоя обычно рассматриваются отдельно когда выставляются требования по высокой доступности. Системам необходимо иметь очень ограниченное время к непланируемым простоям и максимально гибко конфигурированными к планируемым простоям.

Табл.1 Планируемые простои и их решения для семейства продуктов Oracle Fusion Middleware

Операции	Решения
Развертывание и удаление приложений	Hot Deployment
Патчинг	Rolling Patching
Конфигурационные изменения	Online configuration Changes Change Notification Batching of changes Deferred Activation
Масштабируемость	Cluster Scale-Out

Табл.2 Непланируемые простои и их решения для семейства продуктов Oracle Fusion Middleware

Тип сбоя	Решения
Программный сбой	Death Detection and restart using Node Manager for Java EE and OPMN for system components. Server Clusters & Load Balancing Cold Failover Clusters Server Migration Service Migration State Replication and Replica aware Stubs
Аппаратный сбой	Server Clusters & Load Balancing Server Migration Clusterware Integration
Потеря данных	Backup and Recovery
Site Disaster	Oracle Fusion Middleware Disaster Recovery Solution

Решения высокой доступности можно разделить на два вида:

• Локальная высокая доступность – предоставляется в одном датацентре;
• Глобальная высокая доступность – предоставляется в географически различных датацентрах (защищает от региональных бедствий, например наводнений).

Решения локальной высокой доступности можно разделить на два вида:

• «Активный-Активный» - развертываются на двух или более инстансах, которые улучшают масштабируемость и предоставляют высокую доступность . В данном виде все инстансы работают параллельно. Самым ярким примером является кластеризация.
• «Активный-Пассивный» - один инстанс (активный) обслуживает запросы, а другой (пассивный) находится в стадии ожидания. В случае выхода из строя активного инстанса все запросы перенаправляются на выполнение на пассивный инстанс, который становится активным. Пассивный инстанс так же называют standby-инстансом.

Концептуальная схема решения глобальной высокой доступности:

Ошибка "java.lang.AssertionError: Could not obtain the localhost address" при старте Weblogic-сервера и вариант её решения

Ошибка:
При старте Weblogic-сервера возникает следующая ошибка и происходит ошибка старта (сервер переходит в статус FAILED):

 <BEA-000386> <Server subsystem failed. Reason: java.lang.AssertionError: Could not obtain the localhost address. The most likely cause is an error in the network configuration of this machine.  
 java.lang.AssertionError: Could not obtain the localhost address. The most likely cause is an error in the network configuration of this machine.  
     at weblogic.server.channels.AddressUtils$AddressMaker.getLocalHost(AddressUtils.java:38)  
     at weblogic.server.channels.AddressUtils$AddressMaker.<clinit>(AddressUtils.java:33)  
     at weblogic.server.channels.AddressUtils.getIPAny(AddressUtils.java:154)  
     at weblogic.protocol.configuration.ChannelHelper.checkConsistency(ChannelHelper.java:61)  
     at weblogic.server.channels.ChannelService.start(ChannelService.java:207)  
     at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)  
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)  
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)  
 Caused By: java.net.UnknownHostException: vm1.mydomain.com : vm1.mydomain.com 
     at java.net.InetAddress.getLocalHost(InetAddress.java:1360)  
     at weblogic.server.channels.AddressUtils$AddressMaker.getLocalHost(AddressUtils.java:36)  
     at weblogic.server.channels.AddressUtils$AddressMaker.<clinit>(AddressUtils.java:33)  
     at weblogic.server.channels.AddressUtils.getIPAny(AddressUtils.java:154)  
     at weblogic.protocol.configuration.ChannelHelper.checkConsistency(ChannelHelper.java:61)  
     at weblogic.server.channels.ChannelService.start(ChannelService.java:207)  
     at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)  
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)  
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)  

Причина:
По имени хоста (выделено синим выше) на котором напускается Weblogic-сервер невозможно получить его IP-адрес.

Решение:
Варианты решения:

• Прописать в DNS
• Прописать в файл /etc/hosts

Выгрузка данных по измерениям Hyperion EPMA из Oracle RDBMS

1. Подключиться к схеме данных приложения EPMA.
2. Выполнить запрос:
   

    SELECT TYPE_NAME,lpad(' ',2*(level-1))|| member_code AS member_code,  
        alias_default,  
        operation,  
        generation,  
        data_storage,  
        uda_text AS uda,  
        formula,  
        smart_list_name,  
        smart_list_label  
    FROM  
     (SELECT ob_type.TYPE_NAME ,  
      obj.object_name member_code,  
      al.object_name alias_default,  
      obj.generation,  
      obj.parent_id,  
      obj_par.object_name parent_member,  
      (CASE  
       WHEN m.consol_op1=0 THEN '+'  
       WHEN m.consol_op1=1 THEN '-'  
       WHEN m.consol_op1=2 THEN '*'  
       WHEN m.consol_op1=3 THEN '/'  
       WHEN m.consol_op1=4 THEN '%'  
       WHEN m.consol_op1=5 THEN '~'  
       WHEN m.consol_op1=6 THEN '^'  
       ELSE 'Undefined'  
      END) AS operation,  
      (CASE  
       WHEN m.data_storage=0 THEN 'Store data'  
       WHEN m.data_storage=1 THEN 'Never share'  
       WHEN m.data_storage=2 THEN 'Label Only'  
       WHEN m.data_storage=3 THEN 'Shared member'  
       WHEN m.data_storage=4 THEN 'DynamicCalc and Store'  
       WHEN m.data_storage=5 THEN 'Dynamic'  
       ELSE 'Undefined'  
      END) data_storage,  
      uda.uda_text,  
      en.name AS smart_list_name,  
      en.label AS smart_list_label,  
      mf.formula  
     FROM hsp_object obj,    
       hsp_object obj_par,   
       hsp_object_type ob_type,  
       (SELECT obj_al.object_name,al.member_id  
        FROM hsp_alias al, hsp_object obj_def,
             hsp_object obj_al, hsp_object_type ob_al_type  
        WHERE al.aliastbl_id = obj_def.object_id(+) 
         AND al.alias_id = obj_al.object_id(+) 
         AND obj_def.object_name = 'Default' 
         AND obj_al.object_type = ob_al_type.object_type 
         AND ob_al_type.type_name = 'Alias'  
       ) al,  
       hsp_member m,  
       hsp_member_formula mf,  
       hsp_enumeration en,  
       (SELECT uda.member_id,sys_xmlagg(xmlelement(col, ud.uda_value||' ')).extract('/ROWSET/COL/text()').getclobval() AS uda_text  
       FROM hsp_member_to_uda uda, hsp_uda ud  
       WHERE uda.uda_id=ud.uda_id  
       GROUP BY uda.member_id  
       ) uda  
     WHERE obj.parent_id = obj_par.object_id(+)   
      AND obj.object_type = obj_par.object_type(+)   
      AND obj.object_type = ob_type.object_type   
      AND ob_type.TYPE_NAME IN ('Scenario','Year','Time Period','Version','Entity','Account','User Defined Dimension Member' )   
      AND al.member_id(+) = obj.object_id   
      AND m.member_id=obj.object_id   
      AND mf.member_id(+)=obj.object_id   
      AND uda.member_id(+)=obj.object_id   
      AND m.enumeration_id=en.enumeration_id(+)  
     ORDER BY ob_type.TYPE_NAME,obj.generation)  
     START WITH parent_member  IS NULL  
     CONNECT BY prior member_code = parent_member;  
   

3. По результату данного запроса сделать подзапрос по колонке TYPE_NAME (соответствует типу измерения). Варианты:
   
   • Account
   • Entity
   • Version
   • Time Period
   • Year
   • Scenario
   • User Defined Dimension Member