OEM(Oracle Enterprise Mnanager Cloud Control) 12c for MySQL Plugin

■ MySQL plugin 

1.download : 

http://www.pythian.com/resources/dba-resources/the-mysql-plug-in-for-oracle-grid-control-download/

2.install 

http://docs.oracle.com/cd/E24628_01/doc.121/e25161/package.htm#EMPRF12028

[oracle@xxxxx bin]$ ./emcli login -username=sysman Enter password Login successful [oracle@xxxxx bin]$ ./emcli sync Synchronized successfully ./emcli import_update -file=/oradata/swlib1/mysql/12.1.0.1.2_pythian.mysql.prod_2000_0.opar -omslocal [oracle@xxxxx bin]$ ./emcli import_update -file=/oradata/swlib1/mysql/12.1.0.1.2_pythian.mysql.prod_2000_0.opar -omslocal Processing update: Plug-in - MySQL plug-in by Alex Gorbachev, The Pythian Group Successfully uploaded the update to Enterprise Manager. Use the Self Update Console to manage this update. [oracle@xxxxx bin]$ ./emcli sync Synchronized successfully  http://www.aodba.com/en/blog/2014/12/09/add-mysql-instance-oracle-enterprise-manager-12c/ http://www.aodba.com/en/blog/2014/12/09/add-mysql-instance-oracle-enterprise-manager-12c/ [http://www.pythian.com/resources/dba-resources/the-mysql-plug-in-for-oracle-grid-control-download/ ]

3.EM12c Setup

- setup > add target > add target manual > dd Targets Declaratively by Specifying Target Monitoring Properties > Target Typ , Monitroing Agetn > hostname, port , account, password info

- target > all target 

dataguard switchover 시점 기존 primary database 가 자동 재기동 되지 못하는 현상 - Oracle EE 11.2 Dataguard Broker

운영상 문제점이 발생하지 않으므로, 문제점을 갖고 그대로 갈 수도 있다.
하지만, 해결한다면 더 좋은 기회를 얻을 수 있도 있다. 

문제 > switchover 시, 기존 primary database 가 physical standby database 로 재기동 되지 못하는 문제

DGMGRL> switchover to "DB2" 
Performing switchover NOW, please wait... 
New primary database "DB2" is opening... 
Operation requires shutdown of instance "DB" on database "DB" 
Shutting down instance "DB"... 
ORACLE instance shut down. 
Operation requires startup of instance "DB" on database "DB" 
Starting instance "DB"... 
Unable to connect to database 
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor 
Failed. 
Warning: You are no longer connected to ORACLE. 
Please complete the following steps to finish switchover: 
        start up instance "DB" of database "DB" 

해결 > ORA- Error 에서 나타나듯이 Datagurd Broker backgroud process 가 Start 기동 도중 발생 
1. 기동하려는 Database 의 listener 의 상태 확인
2. broker backgroud 가 존재하는 DB의 tnsnames.ora 확인 (양쪽 모두 확인)
3. broker 내부의 parameter 설정 확인 (양쪽 모두 확인)
-> dgmgrl > show database verbose "DB"

edit database 'DB' set property
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostname1)(PORT=1522))(CONNECT_DATA=(SERVICE_NAME=SID_DGMGRL)(INSTANCE_NAME=SID)(SERVER=DEDICATED)))'

infra dba 의 성장

infra dba 의 성장

여러 밴더들이 있겠으나, 좋고 나쁨은 관계없다. 

어차피 회사에서 운영되는 database 는 한정적이다. 

회사에 소속된 dba 라면 그 회사에서 가장 많은 관리 cost 를 필요로하는 database 에 대해 경험하고 성장 할 수 있다. 

물론 책을 통해 study 를 하면서 어느 일정 수준까지의 성장은 가능하다. 

하지만 그것만으로 손에 익을 수는 없고, 자신감을 갖고 관리자로서 컨설팅을 할 수는 없다. 

통합이나 분산이냐의 결정또한 중요하다. 

통합 환경에서 홀로 분산환경을 주장한다면 쟁점이 자주 발생할 것이다. 

반대의 경우도 마찬가지일 것이다. 

high level 관리자 / 사업 관리자라면 밴더에 신경쓰지 않는다. 

비용 / 안정성 을 고려하며 그에 맞는 시니어 엔지니어를 구하면 된다. 

일상의 생각

아침 출근길에 우연히 job search comunity 에 기재된 dba 에 대한 미국에서의 현황에대한 내용들을 접하게 되었다. 

문제의 쟁점은 현재 20년정도 IBM 메인프레임 이나 DB에대해 한가지 외골수적인 성격을 가진 집단에 대한 부러움? 비판? 에 관련된 대화 내용이였다. 

처음에는 공통적으로 대상에대해 바라보는 시선은 20년 이상 한가지 운용지식만을 갖고 같은 일을 해온 50대엔지니어의 안정적인 직장생활에 대한 부러운 시선. 

하지만, 시대는 변해가고, 기술은 발전하기 때문에 수요는 점점 사라지며, 수요 또한 변하기 때문에 언제가는 사라지는 기술이 되어 갈 것이다. 

나는 보통 Oracle DBA 보다 좀 더 빨리 그 수요의 감소를 경험했다. 

항상 고찰되는 문제이지만, 옛날의 아름답던 추억만을 되새기기만하면 안된다. 

뭔가 눈에 확들어올만한 패러다임과 기술을 알게되면 좋으련만, 

glibc version update, loadaverage, kernel version

glibc update 이후, 일정이상 트래픽 발생 후,
load average 가 올라가는 현상

-> kernel 과 glibc library 의 버젼이 맞지 않아 발생

library cache 에 대한 생각

문득 MySQL Architecture 책을 보다가 드는 생각...

왜 Oracle 만 Library cache 라고 하는 Memory 구성을 가지고 있을까?

mysql, mssql, cubrid, postgresql, sybase ...

latch, mutex 등의 기능 구현이 힘들어서?
괜히 만들어서 관리하기만 힘들어서?
기술 특허 문제?

SQL binding 처리, pl/sql .... oracle 의 동시처리를 위한 가장 큰 장점인데,,

oracle 에서 만들었다는 mysql innodb 엔진도 이 부분만 빠져 있다.
일부러 정책상 빠진걸까?
너무 똑같이 만들면 oracle 의 이점이 사라지니?

Database 고르기

너무나 많은 RDBMS , 분산객체들이 존재를 한다. 

10년전까지는 너무나 쉽던 선택들이였는데, 앞으로 10년 후에는 더 많은 변화가 오지 않을까? 

- 비용

- 레퍼런스

- 논리적 구성의 복잡성

- 요구되는 capacity

- 기존 시스템과의 연동