Siebel Maximum Availability Architecture (MAA)

作者: Maclean Liu , post on November 17th, 2010 , English Version
【本站文章除注明转载外,均为本站原创编译】
转载请注明:文章转载自: Oracle Clinic – Maclean Liu的个人技术博客 [http://www.oracledatabase12g.com/]
本文标题: Siebel Maximum Availability Architecture (MAA)
本文永久地址: http://www.oracledatabase12g.com/archives/siebel-maximum-available-arch-maa.html

Agenda

  • Maximum Availability Architecture (MAA)
  • Siebel MAA
    • Target Architecture
    • Oracle Database MAA
    • Siebel High Availability
    • Transparent Application Failover
    • Unplanned Outage Solutions
    • Planned Maintenance Solutions
    • Tips and Best Practices
    • Resources

Load Balancing
Client initiated workload is distributed across multiple component instances running on multiple servers. If an instance or server fails, requests are automatically routed to the remaining instances. Not all components support load balancing.

Distributed Services
Siebel Server initiated workload is distributed across multiple component instances running on multiple servers. If one instance or server fails, the remaining instances take over processing the requests. Not all components support distributed services.

Clustering
Server clusters consist of two or more physical servers linked together so that if one server fails, resources such as disks, network addresses, Siebel Servers and Gateway Servers can be switched over to another server. All components support deployment in a clustered Siebel Server.

In a clustering configuration, each component instance is running in an active/passive mode, however, component instances can be distributed across multiple servers and mixed with load balanced components so that all the available servers are utilized (active) during normal operation. For example, In a two node cluster you’d go with two clustered Siebel Server installations which run on separate nodes when they are available. If one node dies, they would both run on the surviving node.

It is important to plan carefully so that you will have sufficient capacity to run Siebel in the event of node failure.

Recovery time for human errors depend primarily on detection time. If it takes seconds to detect a malicious DML or DLL transaction, it typically only requires seconds to flashback the appropriate transactions. Longer detection time usually leads to longer recovery time required to repair the appropriate transactions. An exception is undropping a table, which is literally instantaneous regardless of detection time.
Data Guard recovery time indicated applies to database and Siebel recovery. Network connection changes and other site-specific failover activities may lengthen overall recovery time.

Performing a rolling patch application with RAC is possible only for patches that are certified for rolling
upgrades. Typically, patches that can be installed in a rolling upgrade include:
Patches that do not affect the contents of the database, such as the data dictionary
Patches not related to Oracle RAC internode communication
Patches related to client-side tools such as SQL*Plus, Oracle utilities, development libraries, and Oracle Net
Patches that do not change shared database resources, such as data file headers, control files, and common header definitions of kernel modules
Do not use Oracle RAC to perform rolling upgrades of patch sets.

Online patches are a special type of interim patch that can be applied while the instance remains online.
Oracle provides online patches when the changed code is small in scope and complexity, such as with diagnostic patches or small bug fixes.
Oracle provides online patches when the patch does not change shared memory structures in the System Global Area (SGA), or other critical internal code structures.
Applying an online patch increases memory consumption on the system because each Oracle process uses more memory from the Program Global Area (PGA) during the patch application. You need to take your memory requirements into consideration before you begin applying an online patch. Each online patch is unique and the memory requirements are patch specific. As is always the case, the best practice is to apply the patch on your test system first. Doing so also enables you to assess the effect of the online patch on your production system and estimate any additional memory usage.


© 2010, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.

相关文章 | Related posts:

  1. Managing Performance and Availability for 25,000 Siebel Contact Center Users with Oracle Real Application Clusters
  2. Performance Tuning Guide for Siebel CRM Application on Oracle
  3. Siebel CRM with Oracle® Cost-Based Optimizer (CBO)
  4. Compare Oracle High Availability to Microsoft SQL Server 2008
  5. Script To Monitor RDBMS Session UGA and PGA Current And Maximum Usage Over Time
  6. Sun SPARC Enterprise MX000 Server Overview and Architecture
  7. Oracle Database 11g: High Availability Student Guide
  8. Using udev with Oracle Architecture (RAC & ASM)
  9. Script:Diagnostic ORA-01000 maximum open cursors exceeded
  10. Design for Higher Availability and Faster Recovery Lawrence To Center of Expertise Worldwide Customer Support Oracle Corporation October 18th,

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>