OS Solaris Operating System (x86) 64bit
상기 OS에
오라클 클라잉언트 10g
오라클 서버 9.2.0.5
환경에서 사용 예정에 있습니다만...
이에 대한 벤치마크 결과 내지는 참고 할 만한 사이트 일러 주심 감사하겠습니다.
특히 스파크와 인텔 두 기종 비교가 되어 있음 더 더욱 좋구요.
많은 조언 기다리겠습니다.
x86 Solaris는 별로 권하고 싶지가 않네요.
과거 x86 Solaris 버젼의 단종을 결심했다가 추후 번복되어진 사연도 있고... 오라클도 9i버젼의 경우 x86 Solaris 버젼 자체가 없지요.
10g부터 지원한다고는 하나 그것도 불확실합니다. x86 Solaris 플랫폼 자체가 앞으로 NT와 Linux에 밀려서 사장될지도 모릅니다.
x86에선 차라리 성능과 안정성 그리고 미래가 보장된 리눅스를 선택하시기 바랍니다.
그런데 64비트인걸 보면 아이테니움인가요? 4G 메모리 제약등도 없어졌으니 괜찮습니다. 스팍과의 비교는 기종에 따라서 다르니 직접 비교는 힘들겠지만... 8-way 이하면 x86으로 가셔도 무방할 것으로 생각되네요. 테스트 장비만 갖추고 계시다면 실재 업무에 사용하고 계신 SQL로 어느 정도의 수행 속도 차이가 나는지 비교 해드릴 수 있습니다.
(장비 업그레이드 시 어느 정도 향상이 이루어지는지 측정 가능함)
플랫폼 선택과 오라클 라이센스에 대해서 궁금한 점이 있으시면 저희 회사로 연락을 주시기 바랍니다. 견적서를 보내드리도록 하겠습니다.
http://www.kova.co.kr 02-566-4941 support@kova.co.kr
김주현님 답변 감사드립니다.
저는 지금 일본의 모 ISP업체에서 DBA를 하고 있습니다.
주로 데이터베이스 설계일을 맡고 있습니다.
좀 더 정확히 말하자면... 논리 설계 위주의 데이터 모델링이 주 업무입니다.
가끔은 튜닝업무도 하긴 합니다.
그런데 시스템 쪽에서 상기 스펙으로 거의 결정이 나서 설치까지 마쳤는데...
이런 의뢰를 하네요.
혹시나 하는 맘에서 그런 것 같은데....
이 부분으론 전혀 감이 안잡혀서.... 질문을 올렸습니다.
제 개인적인 생각인데... 김주현님은 남달리 뛰어난 스킬을 가지고 계신것 같네요.
제가 한국에서 일하면... 정말 많은 도움을 요청할 텐데, 그렇지 못하네요.
이 사이트에서 김주현님의 글을 읽고 많은 공부가 된 사람 중의 한 사람입니다.
찾아보니까. Solaris Operating System x86-64 에 인증된 버전은 10g 버전이네요. 얼마전 출시된 10gR2의 경우도 곧 인증될 예정인가 봅니다.
문제는 아무리 H/W, OS가 64비트라도... 현재 x86 Solaris 버전에 인증된 10gR1은 32비트라서 64비트의 파워를 전혀 발휘할 수 없습니다. 그 이야기는 메모리 제약등이 32비트와 마찬가지로 발생한다는 의미입니다.
H/W는 이미 결정된 것 같으니... OS라도 변경하도록 해보시기 바랍니다. 가능하다면 64비트에서 이미 검증된 Suse나 Redhat Enterprise Linux를 권장드립니다.
(This is a certification only and not a native porting: 32-bit version is certified to install and run on 32-bit and 64-bit. This product will run in a 32-bit mode on this platform. )
그리고 벤치마크는 기존에 운영하시던 것이 있으시면 그대로 데이터 이행하시고 SQL등을 수행시켜 SQL Trace 후 과거와 비교를 해보시면 얼마나 향상되었는지 비교가 가능합니다.
(물론 파라미터와 실행계획이 동일하다는 가정하에서...)
Sort나 Join 형태에 따른 성능 향상, Full Scan의 성능 향상, 병렬쿼리 기능의 성능 향상폭등을 따져보시면 H/W 업그레이드로 얼마나 좋아질지 판단이 서실겁니다. 이게 I/O와 버스 대역폭, CPU 성능등을 종합적으로 측정하는 가장 좋은 방법이라고 개인적으로 생각합니다.
(반드시 직접 테스트해보시고 H/W 벤더의 말에는 휘둘리지 마시구요.)
벤치마크 툴로 진행하는 테스트는 실제 업무환경을 전혀 반영하지 못하므로 결과에 대해서 신뢰할 수가 없습니다.
Ideal 한 상황을 가정하고 테스트를 하지만... 실제로 얼마나 개발자들이 최적화해서 코딩하고 SQL을 잘 작성하고 물리적 구성을 어떻게 해주느냐에 따라서... 아무리 좋은 H/W라도... 조금의 부하에도 병목이 발생하여 주저앉을 수 있습니다.
그리고 현업에서 대개는 업무량에 따라서 적절한 CPU 갯수나 메모리 용량, 필요한 I/O 능력을 과장해서 산정하는 경향이 많습니다.
메모리는 8G, 16G 꽂아놨는데 실재로는 그 정도는 필요가 없는 상황이 된다거나, I/O 능력이 중요한 처리를 하는데 거기에 걸맞는 부품을 갖추지 못했다거나 하는 경우...