分类目录归档:系统层级

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

Oracle RMAN差异备份与累积备份区别

        RMAN是一个专业的数据库备份工具,在RMAN中对数据库进行备份的类型也有很多种。例如下面是两种比较常用的备份类型:完全备份(Full Backup)和增量备份(Incremental Backup)等。 

1 .完全备份 

顾名思义,完全备份是将除空白数据块外的所有数据块、控制文件和日志文件全部进行备份。执行完完全备份后,还可以执行其他备份操作。 

2 .增量备份

在进行增量数据备份时,除空白数据块外RMAN会将发生改变的数据块进行备份操作,而没有任何变化的数据块则不进行任何操作。增量备份的范围可以是单独的数据文件、表空间或者全部数据库。

其中增量备份的方式又分为两种: 

  1. 差异备份   差异备份是默认的备份方式,在备份时需要使用DIFFERENTIAL关键字,它是将备份上一次进行的同级或者低级备份以来所有变化的数据块。 
  2. 累积备份   使用累积备份时需要使用CUMULATIVE 关键字,它将备份上次低级备以来所有的数据块。

采用累积备份还是差异备份,在一定程度上取决于CPU 周期,以及磁盘的可用空间。使用累积备份意味着备份文件将会变得日益庞大,并花费更长的时间,但是在一次还原与恢复过程中,只需要两个备份集。使用差异备份只记录从上次备份以来的变化,但是如果从多个备份集进行恢复,这种操作可能会花费更长的时间。

3 .增量备份的方式

方式

关键字

默认

说    明 

差异备份 

DIFFERENTIAL

  是

  将备份上一次进行的同级或者低级备份以来所有变化的数据块

累积备份 

CUMULATIVE

  否

将备份上次低级备份以来所有的数据块 

例如,在一周之内每天使用的增量备份级别为:0 级、2 级、2 级、2 级、1 级、2 级和2级,下面分别使用这两种备份方式,实现不同的备份效果。

(1 )使用差异增量备份的方式,

周日进行一次0 级增量备份,RMAN将数据文件中所有非空白的数据块都复制到备份集中。 

  • 周一进行级别2 的差异方式增量备份,由于不存在任何最近一次建立的级别为2 或级别为1 的增量备份,RMAN会对周日建立的0 级增量备份相比较,将发生变化的数据块保存到备份集中,即备份周日以后发生变化的数据。  
  • 周二进行级别为2 的差异增量备份,将备份周一以后发生变化的数据。 
  • 周四进行级别为1 的差异增量备份,RMAN将与周日建立的级别为0 的增量备份相比,将那些发生变化的数据块保存到备份集中。 
  • 周五进行一次级别为2 的差异增量备份,RMAN只备份从周四开始发生变化的数据。 
  • 周六进行一次级别为2 的差异增量备份,RMAN只备份从周五开始发生变化的数据。 

使用上述差异增量备份的好处是:如果周五发生故障,则只需要利用周四的1 级备份和周日的0 级备份,即可完成对数据库的恢复。 

(2 )如果使用累积增量备份的方式

  • 周日进行一次级别为0 的累积增量备份,RMAN将数据文件中所有非空白数据块保存在备份集中。 
  • 周一进行级别为2 的累积增量备份。由于不存在任何最近一次建立的1 级增量备份,RMAN以周日的0 级增量备份作为基准,将发生变化的数据块保存到备份集中。即只备份从周日以来发生变化的数据。 
  • 周二进行级别为2 的累积增量备份,RMAN将备份从周日开始发生变化的数据。 
  • 周四进行级别为1 的累积增量备份。RMAN将以周日建立的0 级增量备份为基准,将之后发生变化的数据块保存到备份集中。
  • 周五进行级别为2 的累积增量备份,RMAN将备份从周四以来发生变化的数据。 
  • 周六进行级别为2 的累积增量备份,RMAN将备份从周四建立的1 级备份为基准,将之后发生变化的数据块复制到备份集中,即备份周四以来发生变化的数据。 

在周二建立的2 级增量备份中,实际上包含了周一的2 级增量备份,因此这种增量备份方式称为累积方式。

本文转载自:http://blog.csdn.net/sunansheng/article/details/54893619

Oracle EBS密码策略解析

1. 登录口令失败限制次数:输入一个正整数,表示在禁用用户帐户之前允许用户尝试登录的最大次数。

2. 登录口令应难以猜测:如果要对新口令实施难以猜测的口令验证规则,请将配置文件设置为“是”:密码复杂度包含:

  • 密码至少包含一个字母和一个数字
  • 密码不能包含用户名
  • 密码不能重复某个字母或者数字

3. 登录口令长度:应用用户口令的最小长度,默认为5,可以设置成更大(例如10)。

4. 登录:通知 :Oracle EBS 用户密码错误登录提醒。

–以下供参考

1.Signon Password Failure Limit
输入错误次数限制,一旦被锁定需要系统管理员重置解锁

除了后台表系统中没有的地方可以体现被锁定的现象

此功能使用前11i的可能需要打补丁

因为oracle默认修改密码不是为一次登录所以会出现死循环,具体可以去meterlink上找一下)
2.Signon Password Hard to Guess 密码复杂度
用户的密码中必须至少要有一个字母和一个数字,密码中不能包含用户名,且密码中的字符不能重复。
如某用户的用户名为ABC,则以下密码不被允许:
325763 密码中没有字母
ADFHTR 密码中没有数字
12ABC34 密码中包含用户名
DFGH11 密码中的1重复
3.Signon Password Length密码的最短长度

4.Signon Password No Reuse密码再次重新使用天数
多少天内的密码不能重复使用
一般与 user 界面上的
Define user password expiration一起使用能保证用户的密码定时更换的需要

5.Signon Password Case

密码是否区分大小写。举例来说,某用户的密码AbsF1234,如果不区分大小写,则可以输入ABSF1234或者absf1234。但是如果区分大小写,则必须输入AbsF1234

扩展一:

EBS系统密码分成四类,更改密码都需要遵照章程、规范,特别是做好备份。
1.操作系统用户,如root,ora,appl,grid等用户。 【修改方法】 利用passwd这个OS命令去更改用户密码。 如: passwd root passwd ora passwd apps passwd grid 【生产密码】 pass1234 【注意事项】 无。如忘记root密码,可以用单用户模式登陆OS,以修改root密码。
2.数据库用户,如SYS,SYSTEM 数据库用户,可以用sqlplus或其他客户端登陆,并不能从ERP主页登陆,用数据库命令alter user进行更改。, 【修改方法】 alter user sys identified by pass1234; alter user system identified by pass1234; 注意事项:更改前备份,【sys用户】 create table sys.user$_20140506 as select * from sys.user$;
3.与ERP应用系统有联动的DB用户,如APPS,APPLSYS、AP、INV、GL等。 修改前要备份: create table apps.fnd_user_20140506 as select * from apps.fnd_user; create table apps.fnd_oracle_userid_20140506 as select * from apps.fnd_oracle_userid;
这类用户是DB用户也是ERP系统用户。既会反映在USER$中,又会体现在apps.fnd_oracle_userid中。 这类用户分为三类,如下。
3.1 APPS与APPLSYS用户 [dba_users] [fnd_oracle_userid] FNDCPASS工具会自动将APPS与APPLSYS用户的密码设成一样的。 [appl@erp ~]$ FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS pass1234
注意事项: a.修改密码前,停止整个应用层,特别是并发管理器。 b.修改完时要看日志,看是否有报错,没弄清楚错误前,以及修改完后ERP系统不能正常登陆,都不要手动运行Auoconfig命令、 c.修改完后ERP出现不正常,用以下方法回滚 insert into apps.fnd_user select * from apps.fnd_user_yyyymmdd; insert into apps.fnd_oracle_userid select * from apps.fnd_oracle_userid_yyyymmdd; commit;
3.2 基础模块用户 FNDCPASS apps/pass12340 Y system/pass1234 ORACLE GL pass1234 一次性将所有模块用户做修改的方法,如下: FNDCPASS apps/pass1234 0 Y system/pass1234 ALLORACLE pass1234

3.3 这类是EBS管理的非基础模块用户 需要单独进行密码修改。 SQL> select ORACLE_USERNAME from APPLSYS.FND_ORACLE_USERID where READ_ONLY_FLAG = ‘X’ and ORACLE_USERNAME in (select USERNAME from SYS.DBA_USERS);
ORACLE_USERNAME —————————— ODM –用做数据挖掘的用户 CTXSYS –用做interMedia Text
FNDCPASS apps/pass1234 0 Y system/pass1234 ORACLE “ODM” pass1234 FNDCPASS apps/pass1234 0 Y system/pass1234 ORACLE “CTXSYS” pass1234

4.ERP应用系统用户 用户从Web登陆ERP系统时用的。 这类用户可以通网页自行登录修改,也可以让SYSADMIN管理员帮助修改,也可以让管理员通过OS工具FNDCPASS工具修改。 其中,SYSADMIN最为典型,也是权限非常大的EBS管理员用户,其他的用户有诸如 O-TINA.WANG这些。 这类用户并不是DB用户,并不反映在DB的dba_users表中。 可以从apps.fnd_user中。 SYSADMIN用户 FNDCPASS apps/apps 0 Y system/manager USER SYSADMIN pass1234

扩展二:

/************************************************************
*PURPOSE: To change/reset password of a user from backend   *
*************************************************************/

DECLARE
v_user_name    VARCHAR2(30) := UPPER(‘SYSADMIN’);
v_new_password VARCHAR2(30) := ‘welcome1’;
v_status       BOOLEAN;
BEGIN
v_status := fnd_user_pkg.ChangePassword(username    => v_user_name,
newpassword => v_new_password);
IF v_status = TRUE THEN
dbms_output.put_line(‘The password reset successfully for the User:’ ||
v_user_name);
COMMIT;
ELSE
DBMS_OUTPUT.put_line(‘Unable to reset password due to’ || SQLCODE || ‘ ‘ ||
SUBSTR(SQLERRM, 1, 100));
ROLLBACK;
END IF;

https://blog.csdn.net/laokaizzz/article/details/72783302

http://www.voidcn.com/article/p-zqnldyti-bbz.html

select profile, resource_type, resource_name, limit
from dba_profiles
where resource_type = ‘PASSWORD’
and profile = ‘DEFAULT’;