VRML CARTRIDGE 셋팅과 테스트 방법 - Application Server (Korean)

제품: Application Server
작성날짜 : 1998-02-05
VRML Cartridge 셋팅과 테스트 방법
1. 최초 admin port 로 접속을 합니다. 메인화면이 나오면.
Web Application Server Manager 를 클릭합니다.
Oracle Web Application Server 를 클릭합니다.
Cartridge Administration 를 클릭합니다.
VRML Cartridge(Oracle World) 를 클릭합니다.
Install(Configure) VRML Cartridge(Oracle World) 를 클릭합니다.
Database Username : vrml
Database Password : vrml
Confirm Password : vrml
그리고 아래에서 Create as a New User 를 선택(default)합니다.
DB 와 WAS 가 같은 시스템에 설치되어 있으면
ORACLE_SID 에 해당 SID 를 적으시고
DB 와 WAS 가 같은 시스템에 설치되어 있지 않다면
SQL*Net Connect String:
DBA Username:
DBA Password
를 적습니다.
그리고 Configure VRML Cartridge 를 클릭합니다.
이렇게 하면 vrml/vrml 이라는 DB 유저와 Toolkit 이 생성되고
또 vrml 이란 DAD 까지 자동적으로 만들게 됩니다.(다소 시간이 걸림)
정상적으로 작업이 완료되면 admin port 와 wrb 를 다시 start 해
주시기 바랍니다.
% owsctl stop admin
% owsctl stop wrb
% owsctl start wrb
% owsctl start admin
2. 최초 admin port 로 접속을 합니다. 메인화면이 나오면.
Web Application Server Manager 를 클릭합니다.
Oracle Web Application Server 를 클릭합니다.
Cartridge Administration 를 클릭합니다.
VRML Cartridge(Oracle World) 를 클릭합니다.
Download Client Software 를 클릭합니다.
Client Software 설치(오라클 installer를 이용함)
3. 브라우저에 vrml 을 지원하는 Plug-in 을 Install 해야만 브라우저에서
정상적인 결과를 볼 수 있습니다.
실리콘 그래픽스의 Cosmo Player 나, Sony 의 Community Place 등이
있는데 이 중에 아무것이나 설치하면 됩니다. 가능하면 실리콘 그래픽스의
Cosmo Player 2.0 이 가장 무난할 것입니다.
* URL = http://cosmo.sgi.com/cgi-bin/download.cgi
4. VRML Cartridge Manager(Oracle World Manager) 가 설치 완료되었으면
실행해서 vrml 유저로 DB 에 접속을 테스트합니다.
이때 가능하면 Dedicated 로 접속을 합니다.
tnsnames.ora 에 다음과 같이 지정합니다.
vrml_server =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = IP address)
(PORT = 해당포트)
)
(CONNECT_DATA =
(SID = SID명)
(SERVER = dedicated)
)
)
5. 접속을 하신후에 File --> Import VRML file 을 선택합니다.
여기서 작성된 vrml 파일을 지정하고 확인을 하신후 이름을 임의로
주시면(예 : test) 새로운 ID 를 가지고 import 된 것을 확인하실
수 있습니다.
그러면 다음과 같이 테스트를 하시기 바랍니다.
http://server:port/vrml/vrml.generate_vrml?world_id=해당 ID 번호

Related

WEB APPLICATION SERVER SECURITY / AUTHORIZATION FEATURE :특징

제품: Application Server
작성날짜 : 1997-11-27
Oracle web application server security system
- 각각의 모듈의 역활
.dispacher 는 cartridges 를 필요로 하는 request를 처리
.listener 한 개당 한 개의 dispacher.
.dispacher 는 authentication server, configuration provider, the logger
등의 구성요소로 구성되어있다
.wrb는 모든 cartridges 에 대한 정보와 관리를 한다. network 상에서 한개의
wrb가 존재하며 cartridge에 대한 생성과 제거를 책임진다. 많은 dispacher
가 한개의 wrb에 연결된다
.cartridges 는 server 에서의 application 의 실행과 dispacher 와 listener
를 통해 browser 로 html content 를 보낸다
각각의 cartridge(execution instances : wrbxs) 는 wrb 에 의해 생성되고
제거된다
cartridges 와 listeners 들 사이에는 다대다의 연결 관계가 성립된다
.cartridges 는 db 와 oci(oracle call interface) 나 다른 protocol을 이용
하여 접속한다. db 가 다른 machine 에 있다면 sql*net 을 이용한다
- Security Check Point
. wrb cartridge 에 대한 request 는 dispacher 나 cartrides 자체의
security를 통해 authorization 을 수행한다 ( authorization server에
적용한다 )
. password 는 encrypt 된다 ( secure socket layer protocol 이나 digest
authentication 을 통해)
. static page 나 cgi script 에 대한 http request 는 listener securty 를
통해 인증되고 wrb cartridges 에 대한 request 는 dispacher security 나
catridge 자체에 의해 인증된다.
dispacher 에서의 인증은 authentication server 를 invoke 시키고
Authentication server 의 configuration 에서 인증된다. cartridge 에서의
security는 authentication server 나 그 자체의 internal protection
scheme 을 통해 인증된다
cartridge 에서 최소한의 level 의 protection 을 설정하고 dispacher 에서
부가적으로 protection 을 추가할 수 있을 것이다 두개의 인증을 combine
해서 사용가능. dad 에서 username / password 부여하며 user 에게 접근
가능한 권한을 role 선택
(default,standard, admin )
. listener security 사용가능
. database authentication 을 이용가능 ( username / password 를 configur
-ation file 이나 database 에서 이용가능)
. 네트웍상에서 cartridges 는 wrb에 의해 관리되며 여러개의 listener 가 있다
하더라도 wrb 는 한개가 존재한다
cartridges 를 통한 인증은 동시에 여러개의 listener 와 dispacher 에 적용
된다 (multiple listener)
. listener, dispacher, cartridge based security 는 ip address 와
domain 에 의해 제한되며 username/password 와 combine 되어 적용된다
. http traffic 은 ssl(secure socket layer protocol ) 에 의해 encrypt
된다
. web applicaion server 의 module 은 object oriented architecture 구조
로 network 안에서 분산되어 질 수 있으며 oracle media exchange(omx)
라 불리는 object request broker 위에서 서로 접속가능하다 orb 는 corba
(common request broker architecture)를 기반으로한 object management
기술이다 분산환경에서의 모듈간에는 network traffic 은 encrypt 되어진다
. pl/sql cartridge security 는 url 상에서 직접적으로 invoke 할 수 없도록
configure 가 가능하다
(package_protect parameter : default value TRUE - browser 로 부터
실행가능함을 의미)
- New Feature
. web2.0 은 ssl 2.0 지원 web application server ssl 2.0 , 3.0 지원
. web2.0 의 security 는 모두 listener에서만 수행
. username / password 가 basic ,digest authentication 에서 사용되며
wrb
cartridges protect에서는 encrypted format 되어 저장된다
. web applicaton server 에서는 database authentication scheme 이 추가
됨
. pl/sql cartridge 는 dad에 username/password 에 없다고 하더라도 browser
에서 지원가능하며 새로운 필드추가 ( pkg_protect ) 가 되어서 url 에서
직접적으로 pl/sql procedure control 을 protect 할 수 있다 ( pl/sql
cartridge security )
. web application server 에서는 user 가 작성한 cartridge 에서 직접적으로
authentication server를 invoke 할 수 있다 즉 미리 존재한는 dispacher
authorization schemes 를 이용하여 client 를 인증할 수 있다는 의미
. 분산 환경에서 모듈 간에 수행가능하며 network traffic은 encrypt됨.
( shared key - installing time 시 )
. firewall 사용 가능
1. listener 앞에 : browser와 listener communicaion
2. web application server 뒤에 oracle DB 앞에
3. web application server components 사이에

OPS 구성시 과다 트랜잭션 피하는 방법

OPS로 구성되어 있습니다.
배치를 추가하려고 하는데, 매일 약 백만건 정도를 insert/update 하는 배치 입니다.
과다 트랜잭션및 locking처리가 걱젇되는데요.
각 노드에서 트랜잭션이 빈번하게 발생이 될경우 locking처리가 어떻게 되는지 궁금합니다.
그리고 많이 발생되는 locking을 회피할 수 있는 방법이있는지요. 
한쪽 노드에서 트랜잭션을 수행한다면 문제가 없겠죠?
TAF가 어떻게 구성이 되어 있는지 알 수 없으나
배치작업에 대해서는 load_balance=off 를 통해서
로드밸런스를 하지 않고 한쪽 노드로만 작업을 하게 합니다.
그렇게 하면 양쪽 노드에서 트랜잭션이 일어나서 발생하는
ping 현상이 거의 없겠죠.
OLTP성으로 서비스하는 작업이 아닌, 배치작업이고
실패하더라도 다시 수행하면 되면 문제가 없는 것이라면..
한쪽 노드만 이용하도록 하면 ping으로 인한 contention을
방지할 수 있습니다.
ping이란 rac의 cache fusion의 전단계로 한쪽노드에서 데이터를
변경하였으나, 다른 노드에서 같은 데이터를 변경하려 할 경우
데이터파일에 변경된 데이터를 쓰고 다른 노드에서 다시 그 블록을
읽는 현상을 말합니다. rac의 cache fusion에서는 이것을 interconnect를
통해서 이루어집니다.
OPS의 TAF구성에 대해서 참고자료 드립니다.
-------------------------------------------------------------------------------------
          
No. 17563
OPS의 TAF (TRANSPARENT APPLICATION FAILOVER) 개념 및 구성 (8.1이상)
===================================================================
PURPOSE
-------
Oracle8 부터는 OPS node 간의 TAF (Transparent Application Fail-over)가
제공된다. 즉 OPS의 한쪽 node에 fail이 발생하여도 해당 node로 접속하여
사용하던 모든 session이 사용하던 session을 잃지 않고 자동으로 정상적인
node로의 재접속이 이루어저 작업이 계속 진행하도록 하는 것이다.
이 문서에는 이 TAF에 대해서 간단히 살펴보고 실제 configuration을 기술한다.
Explanation
-----------
TAF가 cover하는 fail의 형태에 대한 설명과, TAF 시 지정하는 fail over의
type과 method에 대해서 설명한다.
(1) fail의 형태:
TAF는 다음과 같은 fail에 대해서 모두 TAF가 정상적으로 수행되게 된다.
단 MTS mode에 대해서는 전혀 문제가 없지만, dedicated mode의 경우는
반드시 dynamic registration형태로 구현이 되어야 정상적으로 TAF가 가능하다.
instance fail: mts의 경우는 문제가 없지만 dedicated mode의 경우는 반드시
dynamic registration 형태로 구성되어야 한다.
fail된 instance 측의 listener가 정상적이라 하더라도,
dynamic registration에 의해서 instance가 fail되면
listener로부터 deregistration되게 되어 listener 정보
를 확인 후 다른 node의 listener로 접속을 시도하게 된다.
그러나 dynamic registration을 사용하지 않게 되면 fail
된 instance 쪽의 listener는 fail된 instance 정보를
services로 보여주게 되고 해당 instance와 연결을 시도하
면서 ORA-1034: Oracle not available 오류가 발생하게 되
는 것이다.
instance & listener down: listener까지 down되게 되면 문제 발생 후
재접속 시도 시 fail된 쪽의 listener 접속이 실패하게 되고,
다른 node의 listener로 접속이 이루어지게 된다.
node down: node 자체가 down되는 경우에도 TAF는 이루어진다. 단 clinet
에 적정한 TCP configuration parameter인 keepalive 의 설정
이 요구되어진다.
node fail시 client와 server간의 작업이 진행중이라면
문제가 없지만 만약 server쪽에서 수행되는 작업이 없는
상태라면 cleint가 node가 down이 되어도 바로 인지할 수가
없다. client에서 다음 server로의 요청이 이루어지는
순간에 client가 더이상 존재하지 않는 TCP end point쪽으로
TCP packet을 보내게 되고, server node가 더이상 살아있지
않다는것을 확인하게 되는데 일반적으로 2,3분이 걸릴수
있다. node가 fail이 된경우 network에 대한 write() function
call이 오류를 return하게 되고, 이것을 client가 받은후
failover기능을 호출하게 되는 것이다.
client에서 idle한 상태에서도 server node가 down되었는지를
학인하려면 TCP keepalive를 설정해야 하며, 이 keepalive를
오라클의 connection에서 사용하려면 TNS service name에서
ENABLE=BROKEN절을 지정해 주어야한다.
DESCRIPTION절에 포함되는 이 ENABLE=BROKEN절에 대한 예제는
아래 구성 예제의 (3)번 tnsnames.ora 구성 부분에서 참조할
수 있다.
이렇게 ENABLE=BROKEN을 지정하면 network쪽 configuration인
keepalive 설정을 이용하게 되는데 이것이 일반적으로는
2 ~ 3시간으로 설정되어 있기 때문에 이값이 적당히 짧아야
TAF에서 의미가 있을 수 있다.
단 이 keepalive time이 너무 짧으면, 그리고 idle한
session이 많은 편이라면 network부하가 매우 증가할 수
있으므로 이 지정에 대해서는 os나 network administrator와
충분히 상의하여야 한다.
이 keepalive 대한 자세한 내용과 설정 방법은 <bulletin:11323:
SQL*NET DCD(DEAD CONNECTION DETECTION)과 KEEPALIVE의 관계>를
          참조한다.
(2) type: session vs. select
session은 유지하고 수행중이던 SQL문장은 모두 fail되는 session type과
DML문장은 rollback되고 select문장은 유지되는 select type이 제공된다.
select type의 경우도 fail된 instance에서만 얻을 수 있는 정보의 경우는
조회수행 도중 다음과 같은 오류를 발생시키고 중단될 수 있다.
예를 들어 해당 instance에 대한 gv$session으로부터의 조회와 같은것이 그
예이다.
ORA-25401: can not continue fetches
(3) method: basic vs. backup
fail발생시 다른 node로 session을 연결하는 basic method와,
미리 다른 node로 backup session을 연결해 두었다가 fail발생시 사용하는
backup method가 존재한다.
Example
-------
TAF설정을 위해서는 init.ora, listener.ora, tnsnames.ora에 설정이 필요하다.
MTS mode에서는 문제가 없기 때문에 여기서는 반드시 dynamic registration으로
설정해야 하는 dedicated방식을 예로 들었다.
test는 Oracle 8.1.7.4/Sun solaris 2.8에서 수행되었다.
A/B 두 node를 가정한다.
(1)initSID.ora에서
- A node의 initSID.ora
service_names=INS1, DB1
local_listener="(address=(protocol=TCP)(host=krtest1)(port=1521))"
- B node의 initSID.ora
service_names=INS2, DB1
local_listener="(address=(protocol=TCP)(host=krtest2)(port=1521))"
service_names는 여러개를 지정가능한데, 중요한것은 두 node가 공통으로
사용할 service name한가지는 반드시 지정하여야 한다.
일반적으로 db_name을 지정하면 된다.
host=부분은 hostname이나 ip address를 지정하면 된다.
(2) listener.ora
LISTENER =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = tcp)
(HOST = krtest1)(PORT= 1521)))
B node에서는 krtest1대신 b node의 hostname혹은 ip address를 지정하면
된다
(3) tnsnames.ora은 지정하는 방법이 두가지입니다.
아래에 basic method와 backup method 두 가지 방법에 대한 예를 모두 기술한다.
이중 한가지를 사용하면 되며 backup method의 fail-over시 미리 연결된
session을 사용하므로 시간이 적게 걸릴수 있으나 반대 node에 사용안하는
session을 미리 맺어놓는것에 대한 부하가 있어 서로 장단점이 있을 수 있다.
두 설정 모두 TAF뿐 아니라 connect time fail-over도 가능한 설정이다.
즉 A node가 fail시 같은 tns service name을 이용하여서 (여기서는 opsbasic
또는 ops1) B node로 접속이 이루어진다.
address=로 정의된 address절이 위쪽을 먼저 시도하므로 정상적인 상태에서
B node로 접속을 원하는 경우는 opsbasic의 경우 krtest2를 위쪽에 적고,
ops1/ops2의 경우는 ops2를 사용하도록 한다.
여기에서 (enable=broken)설정이 되어 있는데 이것은 client machine에 설정되어
있는 TCP keepalive를 이용하는 것으로 network부하를 고려하여 설정을 제거할
수 있다.
a. basic method
krtest1의 tnsnames.ora에서는 opsbasic과 ops2에 대해서 설정해두고,
krtest2 node에서는 opsbasic과 ops1을 설정한 후, backup=ops2를
backup=ops1으로 수정하면 된다.
opsbasic =
(description=
(address_list=
     (enable=broken)
     (load_balance=off)
     (failover=on)
     (address= (protocol=tcp) (host=krtest1) (port=1521))
     (address= (protocol=tcp) (host=krtest2) (port=1521))
)     
(connect_data =
          (service_name=DB1)
     (failover_mode=
     (type=select)
     (method=basic)
(backup=ops2))))
ops1 =
     (description =
     (enable=broken)
     (load_balance=off)
     (failover=on)
     (address=(protocol=tcp)(host=krtest1) (port=1521))
(connect_data = (service_name = DB1)))
ops2 =
     (description =
     (enable=broken)
     (load_balance=off)
     (failover=on)
(address=(protocol=tcp)(host=krtest2) (port=1521))
(connect_data = (service_name = DB1)))
b. preconnect method
아래 예제의 ops1, ops2가 모두 같은 tnsnames.ora에 정의되어 있어야 하며,
ops1을 이용하여 접속하여 krtest1을 사용시에도 미리 backup session을
krtest2에 맺어둔 상태에서 작업하게 된다.
ops1 =
(description =
(address_list =     
(enable=broken)
     (load_balance=off)
     (failover=on)
     (address=(protocol=tcp)(host=krtest1) (port=1521))
     (address=(protocol=tcp)(host=krtest2) (port=1521))
)
(connect_data = (service_name = DB1)
(failover_mode=
     (backup=ops2)
     (type=select)
     (method=preconnect))))
ops2 =
(description =
(address_list=
     (enable=broken)
     (load_balance=off)
     (failover=on)
(address=(protocol=tcp)(host=krtest2) (port=1521))
(address=(protocol=tcp)(host=krtest1) (port=1521))
)
(connect_data = (service_name = DB1)
(failover_mode=
     (backup=ops1)
     (type=select)
     (method=preconnect))))
Reference Documents
-------------------

(V3.0) WAS 3.0 에서 80 PORT 실행 시 에러 처리

제품 : Application Server
작성날짜 : 1997-11-18
(V3.0) Web Applicatoin Server 3.0에서 80포트 실행 시 에러 문제
=============================================================
유닉스 사용자는 1024 이하의 포트에서 웹서버를 사용하고자하는 경우,
"root" 사용자의 권한을 가지고 수행해야만 하는데, WebServer 2.x에서는
퍼미션 변경만으로 해당 프로세스(1024이하 포트)를 수행할 수 있었습니다.
그러나, Oracle Web Application Server 3.0은 다음과 같은 작업이
필요합니다.
1. 관리 리스너(admin)의 소유권 변경
------------------------------------
1) 오라클 웹 리스너 홈페이지로 이동한다.
2) admin의 "CONFIGURE"를 선택한다.
3) 왼쪽아래 프레임에서 "User/Group"을 선택한다.
4) UserID/GroupID를 "root/other"로 변경한다.
5) "Modify Listener" 버튼을 눌러 수정한다.
6) admin 리스너를 종료한다. (root user 로 작업)
% cd $ORAWEB_HOME/bin
% owsctl stop admin
7) "root" 사용자로 로그인하여 admin 리스너를 시작한다.(root user로 작업)
% cd $ORAWEB_HOME/bin
% owsctl start admin
참고) 만약, 4번과정 에서 다음과 같은 메세지가 나오더라도 상관하지말고
계속해주기 바랍니다.
"ERROR OWS-05732: Cannot Change ownership of Listener
Directories."
참고) 7번, "root" 사용자의 프로파일에 다음 환경변수도 설정 해주세요.
ORAWEB_HOME
ORAWEB_SITE
ORACLE_HOME
주의) 만약 DAD 생성시는 반드시 DBA 권한 또한 가지고 있어야 하므로
그룹을 "other" 대신 "dba"로 해주시기 바랍니다.
그러면, 80포트인 "www"리스너를 성공적으로 실행시킬수 있습니다.
2. 두번째 방법으로는 1024 이하의 포트는 모두 "root"로 실행합니다
물론 이것은 기존의 방법처럼 웹브라우저에서 실행및 종료를 하실 수
없습니다.
command line에서 다음과 같이 일일이 실행을 해주어야만 합니다.
root> owsctl start www -> 80포트의 리스너명이 "www"인경우
이것은 설치시 오라클 사용자로 설치하고 "admin"리스너를 오라클
사용자로 실행 시켰기 때문입니다. 그러나, 기존의 방법대로 브라우저
에서도 마찬가지로 1024 이하의 포트를 수행하고자 하면 위 1. 과정
처럼 해주세요.

WEBSERVER를 UPGRADE 후 WARNING MESSAGE가 나올 때 조치 방법

제품: Application Server
작성날짜 : 1998-06-15
WebServer를 Upgrade후 warning message가 나올때 조치 방법
환경 : WebServer 2.1.0 또는 2.0에서 2.1.1로 UpGrade.
1. Admin 화면으로 접속해서 PL/SQL Agent Administration 화면으로 가서
DCD (Database Connection Descriptor) 이름을 Click합니다.
2. 그러면 Modify DCD (Database Connection Descriptor) 화면이 나타납니다.
□ Create PL/SQL Agent Database User
□ Change PL/SQL Agent Database User Password
▣ Install WebServer Developer's Toolkit PL/SQL packages
하단부의 Install WebServer Developer's Toolkit PL/SQL packages을
클릭하고 "Modify Service" 버튼을 누르면 PL/SQL Agent에 맞는 툴킷이
설치됩니다.
이렁게 하면 warning message가 나오지 않게 됩니다.
3. 간편한 방법으로 아래와 같이 할 수도 있습니다.
ows21/admin의 디렉토리로 이동합니다.
여기에 owains.sql, owadins.sql은 WebServer Developer's Toolkit에
관련된 SQL입니다.
$ svrmgrl
$ SVRMGR > connect <dcd의 user id>/<dcd의 user password>
$ SVRMGR > #owadins.sql
$ SVRMGR > #owains.sql
이상은 위의 ②번의 수행 결과와 동일한 내용입니다.
4. OWS 3.0의 경우도 1,2번 또는 3번의 경우와 같은 방법으로 조치 할수
있습니다.

SRKIM: R11i:  ABM Service Start 시 DAC-405 ERROR가 발생하면 CHECK해야 할 사항

Purpose
ABM Service start 시 발생할 수 있는 DAC-405 error 에 대한 조치 방법에 대해 알아 본다.
Question
11i 에서 ABM Service Start 후 Applications 에 접속 하여 ABM Responsibility 를 선택 하면 DAC-405 error 가 발생할 경우가 있는데 이때 check 해야 하는 일반적인 setup 에 대해 check 하는 방법이 무언인지.
Answer
1. osfind 명령어를 실행 하여 Gatekeeper 가 정상적으로 running 중인지 확인 한다.
$cd $<visibroker install dir>/vbroker/bin
$ osfind
위와 같이 명령어를 수행 했을 경우 아래의 내용 처럼 display가 되어야 한다.
osfind: Found one agent at port 14010
HOST: ofsasupport-lx.us.oracle.com
osfind: There are no OADs running on in your domain.
osfind: There are no Object Implementations registered with OADs.
osfind: Following are the list of Implementations started manually.
HOST: ofsasupport-lx.us.oracle.com
REPOSITORY ID: IDL:oracle/jbo/common/remote/corba/RemoteApplicationModuleHome:1.0
OBJECT NAME: oracle.apps.abm.server.AbmSessionAM
REPOSITORY ID: IDL:visigenic.com/gatekeeper/AliasManager:1.0
OBJECT NAME: IIOP Gate-Keeper
2. $<visibroker install dir>/vbroker/bin directory 의 gatekeeper.properties file 의 entry 가 모두 정상적인지 확인한다.
Example:
exterior_port=15000 (Gatekeeper Port)
enable_callbacks=true
ior_file_name=/d01/oracle/visibroker/bin/gatekeeper.ior
log_level=quiet
ORBagentAddr=13x.1.1xx.1xx (IP address of Gatekeeper host)
3. 아래 ABM System profile value 가 정확하게 설정 되어 있는지 확인한다.
Responsibility: System administrator
Navigation Path: Profile > System
ABM: Web Server Host : (Oracle Apps host)
ABM: Web Server Port: (Oracle Apps Port)
ABM: VisiBroker Remote Host Address: (IP address of Gatekeeper host)
ABM: VisiBroker Remote Port: (Gatekeeper Port)
ABM: ORB GateKeeper IOR: (<Oracle Apps URL:>:<Gatekeeper Port>/gatekeeper.ior)
4. vbvars.sh script 의 내용을 review 하여 VB_JRE_TOP 및 OSAGENT_PORT 가 모두 정상적인지 확인한다.
ABM 을 아래와 같이 debug mode 로 수행 하여 나타나는 상세 log 를 확인 한다.
abmsrvst.sh <Osagent Server> <Osagent Port> Y
Example: abmsrvst.sh 138.1.167.199 14000 Y
Reference
Note. 241604.1 - What to Check When Receiving DAC-405 Error Starting ABM

Categories

Resources