1. Rimini Street Inc. 


  A. 소개


    - Chairman : Seth A. Ravin, Board of Directors : http://www.riministreet.com/company/corporate-governance/board-of-directors/seth-a-ravin 

    - Homepage : http://www.riministreet.com/

    - Client : Over 1,450 clients | 115 of the Fortune 500 clients | 23 of the Global 100 clients 


  B. 한국지사

  

    - 2016년 8월 김상열 대표를 한국 지사장으로 선임 - http://www.newswire.co.kr/newsRead.php?no=833292 

    - 한국지사 : 삼성동 Trade Tower 

      

South Korea

-----------------------------------------
Rimini Street, Inc.
33rd Fl., Trade Tower, 511 Young Dong Street , Gangnam-gu, Seoul 06164, Republic of Korea 
Tel +82-2-6007-2200 / Fax +82-2-6007-2001


2. Service


  A. 사업영역


    -- 주요 기업 Products 에 대한 technical support

    -- Rimini Street 의 주장에 의하면, "Oracle 기술지원의 경우 : Oracle 대신 Rimini Street 와 유지보수 계약을 체결하면, 고객은 년간 유지보수 비용을 절감 (Oracle 대비 50% 절감) 하면서 유사한 수준의 기술지원을 받을 수 있음, 대신 Oracle 에서 제공하는 신규 제품에 대한 Upgrade 권리 등은 행사할 수 없다" 정도로 이해됩니다. (http://byline.network/2016/08/1-306/) 


  B. 주요 지원 제품


 Vendor

 주요 지원 제품

 비고

 SAP

비즈니스 스위트(Business Suite), 비즈니스 오브젝트(BusinessObjects), 하나 데이터베이스(HANA Database)

 

 Oracle

시벨(Siebel), 피플소프트(PeopleSoft), JD 에드워즈(JD Edwards), 이비즈니스 스위트(E-Business Suite), 데이터베이스(Oracle Database), 미들웨어(Oracle Middleware), 하이페리온(Hyperion), 리테일(Oracle Retail) 및 애자일 PLM(Oracle Agile PLM) 

 


  C. 주요 미지원 제품 


    -- Oracle Appliance 등

 

3. 저작권 이슈


  A. 저작권 분쟁 중 : 2016년 현재 진행 형


 평결일 

 개요

주요 내용 

 관련 link

 2015.10.13

 재판에서 오라클 임원들과 증인들이 제시한 상세한 증언 및 증거들은 오라클 라이선스 사용권자들이 제3자 지원을 구매하는 것이 합법임을 확인했다

 · 배심원은 리미니 스트리트의 저작권 침해를 인정했지만, 이 침해가 “악의 없음”을 인정 

· 배심원은 이 침해가 “의도적”이었다는 오라클의 주장을 기각 

 URL : 2015-10-13-1

 2014. 2. 13

[미국] 법원, 리미니 스트리트의 오라클에 대한 저작권 침해 재확인

 오라클은 리미니가 오라클 제품의 지원 서비스를 제공하는 과정에서 수차례 저작권을 침해했다는 이유로 소를 제기하였고 법원은 오라클에 대해 일부 승소 판결

  URL : 2014-2-13-1

 

 

 

 


  - URL : 2015-10-13-1 : http://www.newswire.co.kr/newsRead.php?no=807364

  - URL : 2014-2-13-1 : http://www.copyright.or.kr/information-materials/trend/the-copyright/view.do?brdctsno=11378&list.do?pageIndex=1&brdctsstatecode=&brdclasscode=&servicecode=06&nationcode=&searchText=&searchTarget=ALL 




1. OGG 가 복제 소스 서버에서 메모리 사용하는 경우


  -- 기본적으로 복제 Source 서버의 OS Memory 를 사용하도로 설정 됨

  -- v$session 과 v$transaction 등을 모니터링 하다가, 추출 대상이 될 가능성이 있는 변경 사항을 확인하면, OS Memory 를 사용해 cache 하고 있다가, 조건이 충족되면 (예> commit 발생 등) 지정된 Trail 에도 저장

  -- BR 을 사용하지 않는 경우 (11gR2 이상 버전은 BR Enable 이 Default) OS Memory 를 더 사용하는 것 같음 => 이 부분에 대한 근거는 없음

 

2. 사용 메모리 제어방법 


  --  Extract 에 CACHEMGR 옵션을 사용 : OGG 11gR1 - 12cR1 까지 공통사항

-- # MEMORY Env

-- CACHEMGR CACHESIZE 2G

CACHEMGR CACHESIZE 2G, CACHEDIRECTORY /home/oraogg/products/dircache

  # CACHESIZE 2G 를 설정하면, 해당 Extract 는 2G 까지만 OS Memory 를 사용, 별도 Directory 를 지정하지 않아도 됨

  # 설정 된 CACHESIZE 로 부족할 경우, $OGG_HOME/dirtmp 에 기본적으로 저장, CACHEDIRECTORY 옵션으로 특정 Directory 를 지정하는 경우, 해당 Directory 에 임시 파일들을 생성 했다가 지우게 됨 ==> 따라서 어느 정도 까지 해당 Directory 의 space 가 필요할 지는 사전에 계산하기 어려움


 CACHEMGR CACHESIZE 2G, CACHEDIRECTORY /oraogg/temp1 2GB, CACHEDIRECTORY /oraogg/temp2 2GB

  # 이렇게 2개 이상의 Directory 에 각각 Size 가 지정된 경우, 해당 Directory 는 지정된 size 내에서만 임시 파일을 생성, 삭제


ps. 이 내용들은 다음 URL 을 참조했습니다. https://docs.oracle.com/goldengate/1212/gg-winux/GWURF/gg_parameters017.htm#GWURF413 

1. DB Instance 의 Archive Log Mode 초기구성 결과 on 11gR2 


  -- 현재 설정 내용

 

 SQL> connect /as sysdba

 Connected.

 SQL> archive log list 

 Database log mode              No Archive Mode

 Automatic archival             Disabled

 Archive destination            USE_DB_RECOVERY_FILE_DEST

 Oldest online log sequence     36

 Current log sequence           38

 SQL>  



2. Archive Destination 을 LOG_ARCHIVE_DEST_1 로 변경 


  -- fast_recovery_area 에 Archive Log 를 떨어 뜨리지 않기 위해서 등등....


 SQL> alter system set LOG_ARCHIVE_START = TRUE scope=spfile ;      

 SQL> alter system set LOG_ARCHIVE_FORMAT = 'DAPPE02_%r_%T_%S.arc' scope=spfile ; 

 SQL> alter system set LOG_ARCHIVE_DEST = '' scope = spfile ; 

 SQL> alter system set LOG_ARCHIVE_DEST_1 = 'location=/u02/arch/DAPPE02' scope = spfile ; 


 -- DB Instance 재가동이 필요

 SQL> shutdown immediate ; 

 SQL> startup mount ; 

 SQL> alter database archivelog ; 

 SQL> alter database open ;



3. 재가동 후 변경 내용 확인


  -- 항상, 확인은 필요하다.


 SQL> archive log list ;

 Database log mode              Archive Mode

 Automatic archival             Enabled

 Archive destination            /u02/arch/DAPPE02

 Oldest online log sequence     36

 Next log sequence to archive   38

 Current log sequence           38

 SQL> 


  -- 아래의 File name 처럼 생성된다. : 포맷은 위에서 'DAPPE02_%r_%T_%S.arc' 설정 했음 => 지금 보니, 굳이 자리수를 맞출 필요 없이 %T 은 %t 로 했었어도 좋았을 것을...


 oraapp112@mwapp:/u02/arch/DAPPE02] ls -al 

 drwxr-xr-x 2 oraapp121 dba     4096 Aug 10 13:33 .

 drwxrwxr-x 4 oraapp112 dba     4096 Aug 10 13:28 ..

 -rw-r----- 1 oraapp121 dba 15956480 Aug 10 13:33 DAPPE02_919102183_0001_0000000038.arc

 -rw-r----- 1 oraapp121 dba     1024 Aug 10 13:33 DAPPE02_919102183_0001_0000000039.arc

 oraapp112@mwapp:/u02/arch/DAPPE02] 






+ Recent posts