데이터베이스 질문과 답변
by 공은영랄라 [Oracle 기초] 오라클디비 테이블스페이스 Oracle11g OracleDB OracleTableSpace TableSpace [2016.01.26 11:18:23]
저는 오라클에 대해서 아무것도 모르는데요..
회사 그래픽 디자인담당인데.. 개발자분이 잠수타는바람에 SMS 서버를 관리를 맏고 있습니다...
현재 SMS서버는 문자를 1시간에 30만건정도 보내는 솔루션을 사용하고 있는데요..
오라클 11g 디비를 사용하고 있습니다.
현재 서버가 화웨이 서버에 SAS 1.5krpm 정도의스팩을 사용 하고 있는데 제속도가 안나와서 SSD로 교체하려 하는데요..
그냥 하드만 교체해서 하드카피하면 DBF파일이 인식이 안되는것이 맞는것이죠? SAS하드를 제거후에 SSD를 추가해서 기존의 SAS하드의 DBF파일을 복사했더니 서버가 작동하지 않아서요..
제 실력으로 할 수 있는건 최대한 해봤는데 도무지 너무 어려워 엄두가 안납니다..
현재 SAS드라이브는 C드라이브와 D드라이브(1개 분할) E드라이브 이고 SSD는 F드라이브와 G드라이브 입니다.
C드라이브에는 운영체제인 윈도우 서버 2008이 설치 되어있고 오라클 11g가 설치 되어 있으며, 메인 DB(?) 는 분할영역인 D드라이브에 있습니다.
요는 SAS가 제속도를 발휘하지 못해서 계속 SMS가 발송되다 멈춤현상이 발생하는데, 트랜젝션 문제 같아서 SSD로 교체해볼까 합니다.
찾아보니까 오라클디비이동방법이 나와있던데.. 그 방법데로 하면 에러 없이 이동이 가능할까요?
좀도와주십시요!
도망간 개발자가 많은 부분을 하고 있었네용.
또한 그 업무적 책임을 디자이너에게 넘기다니... ㅡㅁㅡ)ㆀ
ㅡ_ㅡ;; 하지 마세요. 아무리 상황이 나빠도 디자이너가 손대면 그 이후.. 여파도 있을 것 같습니다.
당장에 손쓸방법이 없습니다 ㅠ.ㅠ.. 좀 도와주십시요.
어느정도 이해력은 있습니다 ㅠ,.ㅠ....
어차피 해야된다면 이 기회에 배우면서 몸으로 터득할까 합니다.. 어려워도;; 회사조건이 좋기에;; 흐규흐규..
기술적으로 이슈가 많아 보입니다.
SSD로 간다고 속도가 향상되는 것은 아닙니다. 오히려 잘못 구성시 빈번한 로그 작동으로 속도가 저하 될 수 있습니다.
즉 하드 방식만 바꿔서 해결되지 않을 수 있습니다.
SMS 솔루션 로그 등 분석을 통해 근본적으로 원인을 먼저 찾아야 할 것 같습니다.
SMS 솔루션 자체 개발은 아닐 것 같고, 솔루션을 구매하셨을 것 같은데, 해당 업체로 전화 걸어 기술 지원 요청하세요. 1시간에 30만건 보낼 정도면 중점 관리 고객사가 될 것 같은데 문자 발송하다 딜레이 걸린다고 도와달라고 하세용. 그럼 엔지니어 도움 받을 수 있을 것 같습니다.
자체 솔루션이라면 아무튼 통신사 접점 프로토콜까지 분석해야 하는데, 이건 디자이너가 접근해야할 부분은 아닌 것 같습니다.
중간업체인 SK텔링크와 KT크로샷을 통한 로그 분석결과 DB성능저하 이슈가 보인다고 고객사 서버 디스크 I/O를 체크하라고 했었습니다.
서버의 리소스관리 모니터로 모니터링시에 SAS의 디스크의 큐가 SAS에만 과부하가 걸리는것이 확인이 되어서요~
그래서 SAS의 DBF파일을 SSD로 옮겨보려고 합니다.
참고로 화웨이서버에는 SAS 컨트롤러가 내장되어 있지 않아서 SAS가 제 속도를 발휘 할 수 없다고 하네요.. 그래서 SSD로 가보려고 하는거구요~
그 말을 해준 분들에게 SAS 디스크 작업 과부하, SSD로 교체하면 완화 될 수 있을지 한번 물어보세요.
SMS 30만건 발송이 디스크큐가 발생이 많다는 것도 좀 이상한데,
디스크 큐 과부하라고 판단한 내역을 달라고 하여 여따 올려주세요, 무엇인지 같이 봅시다.
안녕하세요
다이얼로그스페이스 정현두입니다.
로그 분석결과 확인된 부분은 다음과 같습니다.
발송 전 DB에 요청한 패치쿼리 소요시간이 일반적인 서버보다 다소 시간이 소요
메시지 발송 후DB에 요청한 쿼리에 대한 큐가 쌓여 데이터의 증가
현재 고객사의 초당 발송건수의 경우 50~60건( 1분에 3000~3600 건가량 )
초당 발송건수가 100건이 되지 못한 부분은 고객사 DB서버 관련 성능상이 이슈가 있어 보입니다.
관련 로그
패치
[2015-12-22 20:43:57,506][INFO ] fetch_time=2543 (cnt:100)
[2015-12-22 20:44:00,002][INFO ] fetch_time=2496 (cnt:100)
[2015-12-22 20:55:26,809][INFO ] fetch_time=1576 (cnt:100)
[2015-12-22 20:55:28,229][INFO ] fetch_time=1420 (cnt:100)
메시지 발송 요청 후 DB 큐
[2015-12-22 20:50:52,248][INFO ] TQ1=35134
[2015-12-22 20:50:53,247][INFO ] TQ1=35334
[2015-12-22 20:55:01,256][INFO ] TQ1=53859, RQ=1
[2015-12-22 20:55:02,255][INFO ] TQ1=54050, RQ=1
초당 발송되고 있는 건수
[2015-12-22 20:49:02,237][INFO ] su=0, sn0=0, [sn1=65, sn2=0, sn3=0, sn4=0], sl=57, r=232
[2015-12-22 20:49:03,251][INFO ] su=0, sn0=0, [sn1=70, sn2=0, sn3=0, sn4=0], sl=33, r=203
[2015-12-22 20:49:04,249][INFO ] su=0, sn0=0, [sn1=65, sn2=0, sn3=0, sn4=0], sl=45, r=183
[2015-12-22 20:55:19,243][INFO ] su=0, sn0=0, [sn1=66, sn2=0, sn3=0, sn4=0], sl=54, r=199
[2015-12-22 20:55:20,241][INFO ] su=0, sn0=0, [sn1=66, sn2=0, sn3=0, sn4=0], sl=40, r=161
[2015-12-22 20:55:21,255][INFO ] su=0, sn0=0, [sn1=45, sn2=0, sn3=0, sn4=0], sl=41, r=94
메시지 대량 발송 대비 DB성능의 저하로 인한 사유이므로 DB서버의 성능점검이 필요해 보입니다.
감사합니다.
이렇게 답변이 왔습니다~ 혹시 로그파일도 필요하신지요?
헌데... 오라클은 유지보수 받고있지 않나요?
단순히 스토리지 이관이라도, 영향을 주는 요소들이 너무 많아서,
오라클 엔지니어 또는 협력사 엔지니어에게 도움 받는게 제일 확실할 듯 한데요.
해당 IDC에 오라클을 다룰줄 아는 엔지니어가 없답니다 ㅠ.ㅠ........
처음 말씀 주신 것은 SMS 보내다 멈춤 현상이고,
위에 문제 제기 내용을 보면, 멈춤 현상 언급은 없고, 성능 때문에 초당 발송 건수가 적다 라는 말인데,
멈춤 현상과 성능상 초당 발송 건수 차이는 풀이가 다를 것 같습니다.
성능상 문제는 SSD를 교체하는 것보다
현 서버 성능 스펙과, 저기서 말한 초당 100건 나와야 한다는 서버 스펙 달라고 하여 스펙을 비교해보시고, 결정을 해야 할 부분 같습니다. 같은 성능이여도, 운용하는 서버 환경에 따라 10-20% 차이는 날 수 있기 때문에 다른 스펙에서 60:100로 차이나는 것은 충분한 지식을 가지고 접근해야 하는 부분으로 여기 댓글 말로서 이거다, 저거다 판단하여 가이드 할 수 있는 부분이 아닌 것 같습니다.
성능상 문제가 아닌 멈춤 현상이라면,
위 단서로는 부족합니다. 로그 파일로 봐도 멈춤 현상이라고 판단 할 수 있는 내용이 있어야 합니다.
패치 타임은 빠른데, DB큐에 있는 것을 솔루션이 빨리 못가지고 가는 것을 성능 탓하고 있는 것이라면 역시 엔지니어 입장에서도 그 말을 한 사람과 상세한 정량적 근거를 두고 풀어야 할 부분인거 같습니다.
일단 계속해서 관심있는 답변 달아주셔서 매우 감사합니다!
구체적 정황을 말씀드리자면,
현재 SMS 발송 서버 사양은
인텔 제온 쿼드코어 2.6G, 16G RAM, SAS 300G(1.5krpm) x 2 , SSD 256G x 2 회선은 100Mpbs(10M트래픽) 화웨이 메인보드를 사용중 입니다.
문자 발송 방식은 저희가 갖고 있는 솔루션(도망간개발자 개발, ASP 웹과 JAVA로 이루어진 것 같습니다..)에서 중개업체(모듈)인 SK텔링크와 KT크로샷(SKT,KT)으로 문자데이터 전송, SK텔링크와 KT크로샷에서 각 통신사로 데이터 전송후 결과값을 받는 방식인 것 같습니다.
줄여 말하면 서버(솔루션) -> SK텔링크 or KT크로샷 -> 각 통신사 서버 -> 결과값 리턴
인것 같은데요!
위의 초당 발송건 문제에 대한 부분은 저희가 발송되다 멈추다 발송되다 멈추다를 반복하여 초당 발송건이 본래의 속도가 나오지 않아서 그렇게 문의 한것 입니다.
서버의 사양이 맨처음에는 SAS 디스크만 있었습니다. 멈춤현상이 어마무시하게 발생하여 SSD를 추가하여 개발자가 DB를 분배해놨었습니다. 그랬더니 조금 나아졌는데 여전히 재속도는 나오지 않더라구요. 그래서 SAS를 아예 제거 후 SSD로만 바꾸어 해보려고 했는데 이때 일이 터져버린겁니다...;;;
우선 확실한 부분은 디스크 I/O 성능 이슈로 트렌젝션 과부화로 인해서 멈추는 부분이 있는건 확실 한 것 같습니다.
현재 C드라이브는 운영체제, D드라이브는 예약 및 기본 테이블 dbf, E드라이브는 당일 발송결과값 테이블(가장 많은 트랜젝션이 발생하는 부분이라 따로 두었습니다.) F드라이브는 SKT 발송, G드라이브는 KT 발송 을 담당하고 있습니다.
현재 가장 걸리는 부분은 RESERVE 테이블(전체예약) 부분인데 이것이 D드라이브에 있습니다. D드라이브는 1번 SAS 하드디스크의 분할 영역입니다. 그래서 과부화가 생기는 것이 아닌지 생각을 해보고 현재 이 사이트를 열심히 찾아서 DBF 파일을 옮겨놓은 상태 입니다. 근데 이 DBF 파일이 RESERVE만 있는것이 아니여서 RESERVE테이블만 따로 DBF로 생성하고 싶은데 도무지 찾아도 나오질 않습니다 ㅠ.ㅠ...
근 한달간 책 찾아보며, 인터넷 뒤져보며 고생했기에 꼭 해결해보고 싶습니다. 솔루션 개발자도 도망간 마당에 처리할 사람은 저밖에 없고 답답해 죽겠네요..
아무튼 계속해서 관심있는 답변 다시한번 감사드립니다.
) 버튼을 클릭하여 작성 하시면 됩니다.