系统层级、经验闲谈

Oracle DataGuard与GoldenGate比较

留下评论

一、复制方式
• Golden Gate
可提供秒一级的大量数据实时捕捉和投递，无法实现同步复制；
• Data Guard
    最大保护—Maximum protection
    最大可用—Maximum availability
    最大性能—Maximum performance
最大保护，最大可用模式都需要同步传输日志，此时会大大加重OracleLGWR或ARCH进程的工作量，严重影响源数据库性能，因此使用DataGuard做容灾一般都采用其最大性能模式中的异步方式。Data Guard的异步日志传输方式有两种方式，一个是通过LGWR进程异步传输Redo Log，另外一种是通过ARCH进程只做归档日志传输。

二、性能比较

• GoldenGate解析Oracle日志，只抓取其中数据变化，大概为原日志量的四分之一左右；GoldenGate还集成了数据压缩功能，压缩比可以达到9:1左右，大大降低了需要在网络上传输的数据量。此外，GoldenGate传输数据是直接通过TCP/IP上进行，无需额外封装；

• Data Guard需要传输Oracle全部的日志，没有压缩功能，在网络上传输的数据量比GoldenGate大很多。它是通过Oracle Net传输数据，其握手信息比较多，相对直接GoldenGate的通过tcp/ip传输效率差很多。

• 综合上述原因，相同状况下GoldenGate的延时要比
Data Guard小很多，容灾系统的RPO会更理想。

三、接管效率

使用GoldenGate复制时，备份数据库是始终处于活动状态，可以随时接管业务；

• Data Guard的备份数据库是处于恢复或只读状态，（Oracle 11g ADG 可以实现恢复的同时只读）如果出现灾难接管业务需要经历两个阶段，第一个阶段是用户查询数据库等待数据库完成日志恢复（Oracle 9i Data Guard只能做归档日志的恢复，只有在10g加入了实时应用的功能可以对未归档日志作恢复）；另外一个阶段是将数据库由备份状态改成主数据库状态。这两个阶段根据实际经验一般至少需要5分钟以上时间。

• 由此可见，使用GoldenGate的容灾系统RTO相对更短，有利于保障业务的连续性。

                      

 

系统层级、转载文章（档）

Oracle EBS R12启用HTTPS安全链接(SSL）

留下评论

        E-Business Suite R12.1.1 provides Advanced Configuration wizards that make it easier to deploy features such as SSL and load-balancing.  Apps administrators can use these wizards to make configuration changes online through Oracle Applications Manager (OAM) and then run AutoConfig on the applications tier to make the changes effective.

       SSL (Secure Sockets Layer) is one of the most commonly used configurations in EBS. I'll walk through the SSL Advanced Configuration Wizard in this article.

Accessing the Advanced Configuration Wizards

Launch the Oracle Applications Manager Site Map using the System Administrator responsibility, then select the AutoConfig link from the Administration tab.

 

Click on Launch Wizards. It brings up the launch pad for five wizards:

  1. Forms Socket Mode
  2. SSL
  3. SSL Accelerator
  4. HTTP Load Balancing 
  5. OC4J Load Balancing

Start the SSL Configuration Wizard

The OAM General Collection Service must be activated before running any configuration wizards.  From the Administration tab of the Site Map, click on the 'Generic Services' link under the Application Services. Select 'OAM Generic Collect Services' and start it for the target instance. OAM submits a concurrent request for the same. Click on Verify to see if the service starts up fine. Once the service starts, you are ready to use the wizard.

From the Configuration Wizards launch pad, click on the 'Enable' button for SSL.

Select Nodes to be SSL-Enabled

Select the nodes on which you would like to enable SSL and click 'Next.'

2. Set Context variables for SSL

Notice the tip at the bottom of the Parameters screen:  you should make sure that your digital certificates are properly imported into the Wallet of your EBS instance. For details about importing SSL certificates, see:

 

The wizard sets the following context variables to 'https': 

  • URL protocol
  • Local URL protocol

It also sets values for the 'Web SSL directory' and the 'Active HTTP SSL port.' The subsequent screen gives the current and new values for these variables.

3. Validation

The wizard validates all settings when you click 'Next' after the user comparison of context values screen.  It checks that the Wallet and the required directory structures exist.

Make sure that the Status is 'Success.' Check the log file in the 'View' link for any errors.

4. Confirmation Page

Clicking 'Next' will take you to the Confirmation Page in the train cart. Click on the link below to check the confirmation page.

5. Submit the changes and run AutoConfig

Clicking the 'Submit' button on the Confirmation page displays the next action to be taken. You can review the context file on the applications tier for the changes that have been made. 

The next step is to run AutoConfig to propagate the changes. You need to restart all application services to make the changes effective.

Once the service have been restarted, the EBS instance is ready to be used in SSL mode.

转载自：http://blog.csdn.net/sunansheng/article/details/45848783

系统层级、转载文章（档）

Oracle的单点登录解决方案（Single Sign-On Solution）

留下评论

        Single Sign-On(SSO)即单点登录，在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。在此条件下，管理员无需修改或干涉用户登录就能方便的实施希望得到的安全控制。

        Oracle现有两套单点登录的解决方案：Oracle Access Manager，Oracle Single Sign-On Server (OSSO)。
Oracle官方推荐Access Manager作为SSO的解决方案，Oracle Single Sign-On Server的高级用户最终也会建议迁移到Oracle Access Manager解决方案上。

(来源：Note 1461465.2 – Information Center: Overview EBS Technology Stack OID and SSO and OAM）

OAM SSO实现方式有两种：一种是通过OAM Agent(WebGate)，另外一种是使用OSSO Agents（mod_osso)

1.) 使用OAM Agent(WebGate代理),然后和Oracle E-Business Suite Access Gate集成(此处以EBS为例).

WebGate是Web服务器的一个插件，用于拦截HTTP请求，并把请求导向Oracle Access Manager (OAM)来获取用户认证。

OAM SSO登陆的过程描述：

When a user tries to access a protected application, the request is received by OAM which checks for the existence of the SSO cookie.

After authenticating the user and setting up the user context and token, OAM sets the SSO cookie and encrypts the cookie with the SSO Server key (which can be decrypted only by the SSO Engine).

Depending on the actions (responses in OAM 11g) specified for authentication success and authentication failure, the user may be redirected to a specific URL, or user information might be passed on to other applications through a header variable or a cookie value.

Based on the authorization policy and results of the check, the user is allowed or denied access to the requested content. If the user is denied access, she is redirected to another URL (specified by the administrator in Webgate registration).

可以看到，Oracle OAM通过Cookie存储用户的信息，进而通过Cookie来实现单点访问授信站点。

2.) 使用mod_osso代理，这种方法只适用于从Oracle Single Sign-On Server 10gR3升级上来的用户。

详细见：About SSO Log In Processing with OAM Agents中的“About SSO Login Log In Processing with OSSO Agents (mod_osso)”

关于Cookie

Cookies就是服务器暂存放在你的电脑里的资料( 用户ID，密码、浏览过的网页、停留的时间等信息)，好让服务器用来辨认你的计算机。 当你在浏览网站的时候，Web服务器会先送一小小资料放在你的计算机上，Cookies 会帮你在网站上一些内容都记录下来。当下次你再访问同一个网站，Web服务器会先看看有没有它上次留下的Cookies资料，有的话，就会 依据Cookie里的内容来判断使用者，送出特定的网页内容给你。 一般来说，Cookie通过HTTP Headers从服务器端返回到浏览器上。IE Cookies 文件夹路径保存于注册表：HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cookies

See Also:

Oracle LDAP解决方案 – Oracle Identity and Access Management Suite :http://blog.csdn.net/pan_tian/article/details/20927733

About SSO Log In Processing with OAM Agents

Overview of Single Sign-On Integration Options for Oracle E-Business Suite [ID 1388152.1]
Integrating Oracle E-Business Suite Release 11i with Oracle Access Manager 11gR2 (11.1.2) using Oracle E-Business Suite AccessGate [ID 1536941.1]

Oracle Access Manager 11.1.2 Certified with E-Business Suite 12 

Oracle Access Manager 11.1.2 Certified With E-Business Suite 11i
Introduction to Installing WebGates

转载自：http://blog.csdn.net/pan_tian/article/details/8691726

系统层级、经验闲谈、转载文章（档）

Oracle EBS AutoConfig详解

留下评论

Oracle Apps AutoConfig – Paul's Notes – CSDN博客

一、Background

Oracle Apps的架构非常复杂，使用了非常多技术（或服务）。比如Apache Web server, Apache Jserv, Forms Listener servlet (或forms server) 等等，每一个服务都有着自己的配置文件，只有都设置正确了，系统才能正常运作。而且，Oracle Apps使用了许多的Profile Options（比如Applications Web Agent, Applications Framework Agent等），这些也需要都设置正确，人工管理这么多配置文件，其实并不容易，对于新人来说，学习成本很高。

所以Oracle推出了一个非常强大的工具–Autoconfig（Autoconfig是11.5.4后引入的），用于维护这些配置文件和Profile Options。我们可以认为AutoConfig是一些系列模板化配置文件的集合，用于配置出一个标准化的应用环境。

二、什么是AutoConfig

AutoConfig是集中并简化Oracle Apps的配置管理的工具，一个自动配置EBS Instance的工具，不需要手工干预。它所需要的信息仅仅是两个存储在本地Context文件（XML类型的文件），一个是Apps Context文件，另外一个是DB Context文件。

AutoConfig在Apps层运行的话，那么它就需要读取Apps Context文件来产生所有的配置文件，并且会更新数据库的Profiles。

如果AutoConfig在DB层运行的话，那么它就需要读取DB Context文件来产生所有用于DB层面的配置文件。

AutoConfig内部其实是一组Java Class文件，这些Class文件由Shell脚本(或者perl脚本)来调用，通过模板化的配置来维护系统的配置文件。Autoconfig运行时，会用新的配置文件重写已存在的配置文件（这个新的配置文件其实是：模板配置文件+context文件，构建而成的）

总之：AutoConfig确实很好的简化了系统的配置工作。

三、AutoConfig脚本所在的目录

Application tier: <INST_TOP>/admin/scripts/adautocfg.sh

                            (eg./u01/oracle/mc3yd213/inst/apps/mc3yd213_bej301441/admin/scripts/adautocfg.sh)

Database tier: <RDBMS_ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>/adautocfg.sh

                          (eg./u01/oracle/mc3yd213/db/tech_st/11.1.0/appsutil/scripts/mc3yd213_bej301441/adautocfg.sh)

四、运行方法

Apps Tier:

sh <INST_TOP>/admin/scripts/adautocfg.sh 

注意：

  • 在运行AutoConfig的过程中，Database server和database listener必须已经启动，Apps Server应该处于关闭状态。
  • Running AutoConfig may change your existing environment files. After running AutoConfig, you should always set the environment before you run any Applications utilities, in order to apply the changed environment variables.

DB Tier:

sh <RDBMS_ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>/adautocfg.sh

注意：

  • 在运行AutoConfig的过程中，Database server和database listener必须已经启动，其他数据库服务应该处于关闭状态。
  • Running AutoConfig may change your existing environment files. After running AutoConfig, you should always set the environment before you run any Applications utilities, in order to apply the changed environment variables.

五、AutoConfig工作原理

Autoconfig会涉及三类文件：Context文件，Template文件，Driver文件。

六、Context文件

Context文件可以说一个记录环境参数的基础文件，它存储了Apps所有的配置信息，如果需要更改某项配置，则需要首先修改Context文件的配置信息，然后在通过AutoConfig，把更改的信息更新到所有的真实配置文件中去。

Apps Context文件：<INST_TOP>/appl/admin/<CONTEXT_NAME>.xml (eg./u01/oracle/mc3yd213/inst/apps/mc3yd213_bej301441/appl/admin/mc3yd213_bej301441.xml)

DB Context文件：<RDBMS_ORACLE_HOME>/appsutil/<CONTEXT_NAME>.xml(eg./u01/oracle/mc3yd213/db/tech_st/11.1.0/appsutil/mc3yd213_bej301441.xml)

NOTE:<CONTEXT_NAME> = <SID>_<hostname>

七、AutoConfig模板文件

用于生成配置文件的模板，Apps里的每一个配置文件都有一个对应的模板。模板文件中包含了很多的Tag，这些Tag最终会被Context文件中环境变量替换掉。

模板文件存放的地方: 

Apps层的模板文件：<product_top>/admin/template，比如: <FND_TOP>/admin/template (eg./u01/oracle/mc3yd213/apps/apps_st/appl/fnd/12.0.0/admin/template，打开目录能看到很多tmp的模板文件)


DB层的模板文件：<RDBMS ORACLE_HOME>/appsutil/template，比如<ORACLE_HOME>/appsutil/template(eg./u01/oracle/mc3yd213/db/tech_st/11.1.0/appsutil/template)


 

八、driver文件

Driver文件会列出了AutoConfig模板文件路径以及模板文件对应的目标配置文件的真实路径，以及一些脚本命令。

Apps的Driver文件位于：<product_top>/admin/driver，比如: <FND_TOP>/admin/driver(eg./u01/oracle/mc3yd213/apps/apps_st/appl/fnd/12.0.0/admin/driver,里边有很多.drv文件)

DB的Driver文件位于:<RDBMS ORACLE_HOME>/appsutil/template，比如<ORACLE_HOME>/appsutil/template(eg./u01/oracle/mc3yd213/db/tech_st/11.1.0/appsutil/template里的.drv文件)

每当Autoconfig运行的时候，都会在先找到Driver文件，然后按照Driver文件提供的脚本命令，模板文件，以及Context文件生成目标配置文件。

九、AutoConfig的日志文件

Application Tier: <INST_TOP>/admin/log/<MMDDhhmm>


Database Tier:   <RDBMS ORACLE_HOME>/appsutil/log/<CONTEXT_NAME>/<MMDDhhmm>

                          eg./u01/oracle/mc3yd213/db/tech_st/11.1.0/appsutil/log/mc3yd213_bej301441/05240310

<MMDDhhmm> = (month, day, hour, minute of AutoConfig run)

十、AutoConfig配置回滚

每一次AutoConfig的运行都会产生一个回滚脚本，如果AutoConfig配置错误，你可以使用回滚脚本来恢复之前的配置。

Application Tier:     <INST_TOP>/admin/out/<MMDDhhmm>
Database Tier:    <RDBMS ORACLE_HOME>/appsutil/out/<CONTEXT_NAME>/<MMDDhhmm>
并且运行命令:  restore.sh(Unix) 或者restore.cmd(Windows)

十一、Autoconfig Context文件的修改

路径:System Administration > Oracle Applications Manager > AutoConfig
从列表中可以看到DB层和Apps层的Autoconfig Context文件

点击Edit Parameter,可以在这里修改Context File的Parameter,在这里改Context文件应该比直接修改Context的XML文件更安全些。

从截图的页签，也可以看出，Autoconfig Context的配置主要涉及到Global，System，Local，Install，Environments，Processes，Custom几块。

十二、Reference about AutoConfig

http://www.appsdba.info/docs/oracle_apps/R12/AutoConfig.pdf

387859.1  Using AutoConfig to Manage System Configurations in Oracle Applications Release 12

Autoconfig in Oracle Apps 11i / R12 / 12i

165195.1  Using AutoConfig to Manage System Configurations with Oracle Applications 11i

218089.1  Autoconfig FAQ
270519.1  Customizing an AutoConfig Environment
364927.1 How To Run Autoconfig On Database Tier (DB-Tier)
341322.1 How to change the hostname of an Applications Tier using AutoConfig
338003.1 How to change the hostname and/or port of the Database Tier using AutoConfig
315674.1 How To Verify if Autoconfig is Enabled on 11.5.x
391406.1 How to get a clean Autoconfig Environment

转载自：http://blog.csdn.net/sunansheng/article/details/46501335

系统层级、经验闲谈、转载文章（档）

Oracle EBS的组织架构介绍

留下评论

一、Oracle EBS的组织架构

        软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。 
        ORACLE  EBS系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、库存组织（Inventory Org）”等，与企业实际的行政组织不是完全等同的概念，而是基于系统业务运作需要而设定的。

二、业务组（BG，Business Group）

“业务组”的概念可以视同企业的“集团”概念，但不同的是一个企业在系统中可以设置多个“业务组（集团）”。 
通常对于一个企业来说，系统中有一个“业务组”就够了，这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司（如跨国公司），则可能需要在系统中设置多个“业务组”，表示企业由多个“集团公司”组成。 
业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关，即“人员信息”的设置在一个BG范围内是由各业务模块共享的（如果需要）。一旦系统设置的用户名（User）被与“人员”（Employee）关联，无论使用什么“责任”进入系统，都会定位至一个确定的BG中，任何责任在任意时刻只能关联一个BG。EBS安装好后，系统里面已经预置了一个名为“Setup Business Group”的“初始业务组”。

三、法律实体（LE，Legal Entity）

对应实际的按国家法律法规注册的法人公司。 
R12中在定义“分类帐”时的“会计科目设置管理器”WEB中定义并分配法人实体LE。一个分类帐设置（主辅分类帐）可以添加多个LE，但每个LE只能具有一个分类帐设置。 
业务实体（OU，Operating Unit）是EBS系统组织设置的重点也是难点之一。它与法人主体LE本身没有必然的关系，与会计科目弹性域结构中的“公司段”也没有直接关系。
从企业实际业务管理需要的角度去看，业务实体OU可以看作是在系统中按照业务的相似性，把多个不同公司（包括LE）的业务处理过程及数据划分成相对独立的“管理单元”。在每个管理单元内部，各公司的业务运作共享相关数据并执行统一的业务策略。

四、库存组织（Inventory Org）

不是真实业务的“仓库管理部门”那么简单，它除了是有“物料接收与发出”等业务功能之外，更重要的是，它还是EBS系统有关计划（MPS主生产计划/MRP物料需求计划）、在制品管理（WIP）、物料清单（BOM）等模块业务功能的操作与管理平台。 
在EBS中还有两个组织概念“MRP组织、WIP组织”，它们实际是必须构建于库存组织之上的组织概念，表示该库存组织还可以进行MRP或WIP的功能。系统之所以如此处理，主要是为了控制某些INV不能做MRP或WIP而已，因为基于物料接收或发出需要所设定的INV数量可能比较多。
对于绝大多数基于库存组织INV的业务功能（个别除外），系统用户在做业务操作时，均必须首先进行INV的选择切换，以便进入确定的INV上下文环境。库存组织的作用是如此基础，以至于EBS的相关文档在提及组织（Org）概念时，如果未作特别说明，默认就是指INV组织。 
一个库存组织INV只能属于一个确定的帐套SOB、一个确定的法人实体LE、一个确定的业务实体OU。反之，一个“帐套/法人实体/业务实体”组合则可以有多个库存组织INV。 

五、HR组织

系统的HR组织设置是与HRM模块的相关业务处理功能相关，与核心业务、财务处理功能关系不大

六、资产组织

“资产组织”的设置，它是在企业需使用到资产管理模块FA时才涉及到。“资产组织”实际上是所谓“资产账簿”的代名词，它只是表示有关资产信息的一个数据维度，作用主要在于分隔数据范围

七、多组织访问控制

EBS组织设置界面中，所谓的组织“类型”（Type）划分仅是基于组织自身的统计分析工作需要而定义的一个“维度”，例如“公司总部、产品线”等等，并不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类”，系统预置的组织分类LOV除了上述“业务组、法律实体、业务实体、库存组织”等之外，还有诸如“资产组织、运营公司、雇主”等等选项。在EBS系统中各应用模块所具有的业务处理功能通常需构建在一个确定的“组织分类”之上，“组织”是相关业务处理功能的平台，企业是否需要作相关组织分类设置、如何设置，取决于企业所需要使用到的应用模块功能。
ORACLR系统通过“组织”所具有的“层次结构”（Hierarchy）概念来达到“多组织访问”权限的控制功能。
这里的组织“层次结构”与真实企业的行政管理组织层次结构没有直接关系（尽管可能有所参考），它只是企业根据某种需要（如权限管理控制、数据统计汇报等）而人为设定的一个“层次结构”，例如将系统中已经设置的任意数量的“业务实体”或“库存组织”等组织，人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。

八、配置文件

所有定义的“安全性配置文件”构成系统多组织接入控制参数“MO：安全性配置文件”的LOV
EBS 通过“MO：业务实体”、“MO：安全性配置文件”、“MO：默认业务实体”这三个系统配置文件的共同作用，实现所谓“多组织访问”控制功能。 
对于“MO：业务实体”：在R12中， 一旦设定“MO：安全性配置文件”，则此配置文件失效而不起作用。 
对于“MO：安全性配置文件”，：在R12中，该参数如果不设定，则必须设定“MO：业务实体”参数；一旦该参数被设定，则就起决定作用，系统主要依赖其实现“多组织访问”控制功能。 
对于“MO：默认业务实体”： 在R12中，随“MO：安全配置文件”起作用后才起作用，其LOV是所有已定义OU，但如果设定值不在“MO：安全配置文件”所选择的“组织层次架构”的范围内，则仍不起作用（即在与OU相关诸如PO、OM等的FORM界面，OU字段的默认值仍然为空）。 
ORACLE强调其“多组织接入MOAC”功能主要是针对业务实体OU而言。库存组织的访问是在“组织访问”控制功能中，专门设定“库存组织”与“责任”的关联性 。
EBS系统通过“弹性域段值安全性”、“帐套/分类帐安全性”、“多组织访问控制（MOAC）”、“库存组织访问控制”等多维度、多方面的组合系统设置，提供了灵活、方便的用户权限管理功能，理清并掌握它们的复杂关系是系统实施的一项重要基础性工作。

转载自：http://blog.csdn.net/sunansheng/article/details/72636643

技术笔记（小潘的技术记录博客）