안녕하세요, 100여명 규모 병원에서 1인 전산일을 하고 있는 담당자입니다.
DB유지보수 업체랑 의견이 좀 안 맞아서 의견을 여쭙고자 질문드립니다. 일단 저는 DB쪽은 개념이나 쿼리 구조만 대충 아는 수준입니다. 대신 하드웨어 사양은 남아 도는 수준으로 널널한 편입니다.
계속해서 여러 부서에서 프로그램 동작이 느리다는 말이 나오고 있었고, 실제로 조회를 누르면 자료가 많은 환자는 10초 이상 로딩이 걸리는 경우도 있습니다. 한 화면에 여러 테이블 자료를 다 끌어오는 거라 어느 정도 느릴 수도 있겠다 싶었는데, 그래도 조금이라도 빠르게 만들 수 없을까 싶어 찾은게 reorg와 인덱스 리빌드 였습니다.
아래 링크는 제가 reorg가 필요하겠다고 판단하게 된 쿼리 정보? 입니다.
https://www.support.dbagenesis.com/post/remove-table-fragmentation-in-oracle
통계자료 생성 후 테이블 사이즈 체크를 하면 대부분 50%가 넘어가서 업체에 reorg가 필요한 것 같다고 얘기했는데 여기서 의견차이가 생겼습니다.
업체의견 : DB 사이즈가 큰 편이 아니기 때문에 단편화에 따른 영향력이 미비한 수준이다.
>> 용량 순으로 3.8, 3.3, 2.7, 2.6, 2.6, 2.1, 1.3, 1.2까지 총 8개 테이블만 GB단위입니다. 그 외 테이블들이 많긴한데 1G 근접한건 몇개 없고 보통 200M나 60M수준입니다.
제 의견 : 단편화 20%부터 성능에 영향을 준다는데 벌써 50%가 넘었고 지금껏 한 적이 없으니 진행했으면 한다.
>>아무래도 정확히 알지도 못하고.. 24시간 업무라 별 효과도 없는데 서비스를 멈추면서까지 하기는 부담스러워 확실하게 주장을 못하고 있습니다...
질문입니다.
1.위 링크 사이트에서 제공한 쿼리가 단편화%를 정확하게 나타내고 있는게 맞을까요?
2.정말 DB 용량이 작으면 굳이 reorg 같은 작업은 필요가 없거나, 해도 별 차이가 없는지요?
3.만약 reorg를 한다면 지금까지 reorg를 한적이 없으니 모든 테이블을 작업하는게 맞을까요?
오며가며 보신다면 답변 부탁드리겠습니다. 감사합니다!
6개의 답변이 있습니다.
10년이상 전에만 해도 H/W 사양이 많이 낮고,
디스크의 성능도 떨어지는 상황이어서 주기적으로 reorg를 주기적으로 하는 것을 많이 봐왔습니다.
최근에는 DB 엔지니어들과 얘기를 해 보면,
reorg 작업 보다는 오히려 H/W 증설을 해 주는게 오히려 작업도 편하고,
성능 향상도 눈에 띄게 볼 수 있다고 얘기들 하더라구요.
100% 필요 없지는 않겠지만, 다른 방법도 있으니 검토 해 보세요~~
답변주셔서 모두 감사드립니다.
기껏 답변 주셨는데 제가 중요한 내용을 안 적었었네요... 병원 커스텀된 DB가 아니라 상용 프로그램에서 제공하는 DB라 쿼리나 테이블 구조를 변경할 수가 없습니다..
그래도 전체적인 답변 방향을 보아 reorg가 무조건 성능향상으로 이어지는 건 아니라는 것은 알게되었습니다. 나중에 서비스 중지 스케줄이 생기면 그때 맞춰서 고용량 테이블 위주로 요청해봐야 겠습니다.
다시 한 번 답변 감사합니다!!
기본적으로 데이터 가져오는 인덱스 구조를 잘 설정 하셔야 합니다. 테이블 DROP&CREATE 하거나
REORG 해도 크게 변화가 없다면 인덱스와 쿼리 구조 문제 입니다.
문제되는 쿼리 들을 하나하나 살펴 보시기 바람니다.
성능 이슈가 있고... 이에 대한 개선 방안을 찾아야 하는 상황인것 같은데요.
가능한 비용을 들이지 않거나 적게 들이고 해결할 수 있는게 가장 좋겠고...
상황에 따라서는 큰 비용을 소비하면서라도 해결 방법을 찾아야 할 수도 있겠고요.
DB 업체에서 제안하는 방안이 있나요?
현재의 성능 문제를 해결하기 위해 DB 업체에서는 어떤 방법을 제안하는지를 확인해 볼 필요도 있을 것 같고요.
후보안들을 쭉 정리해 두고서, 가장 접근이 쉬운 방법 부터 시행해 보는게 맞지 않을까 싶어 보이네요.
실 운영 서버로 부담이 생긴다면 유사한 성능의 하드웨어를 준비해 두고서 시험 운영 서버를 구성해 두고서 Test 해 보는 것도 검토해 볼 필요가 있을 것 같아 보이고요.
큰 비용을 투자해서 성능 개선을 시도하기전에 DB 최적화 작업을 우선해 보는게 순서가 아닐까 싶습니다.
DB 최적화로 큰 효과를 얻지 못한다면 처리 소프트웨어를 최적화하는 방안으로 불필요한 오버헤드를 줄일 수 있는 방법도 검토해 볼 필요가 있을 것 같아 보이고요. 예를 들어 모든 자료를 한번에 무조건 읽는 대신에 꼭 필요한 만큼만 읽어 들였다가 추가적으로 확인 필요할때 추가 데이터를 읽어 와서 표시하는 방식으로 프로그램을 수정하는 것도 검토해 볼 수 있을 것 같고요.
소프트웨어적인 방법으로 해결 방법이 없다면, 하드웨어적으로 시도를 해야 할 것 같고요.
DB로 부터 Data를 읽어 오는 과정에서 시간이 많이 소요된다는 것은 Disk I/O와 관련 높을 가능성이 있기 때문에 저장 장치를 플래시 장치로 교체하는 것도 검토해 볼 필요가 있을 것 같아 보이고요.
업체에 잘 이야기해서 문제 해결을 적극적으로 지원해 줄 수 있도록 유도하는 게 필요할 걸로 보이네요.
말씀하신 단편화, 즉 update, delete가 잦은 테이블은
Reorg(data reorg, index rebuild)를 주기적으로 하는게 좋긴 합니다.
단편화된 테이블이 많이 있다면 Reorg는 그렇게 어려운 작업이 아니기에
한번 진행하시는게 좋습니다.
다만, Reorg 작업 진행동안 시스템의 퍼포먼스, 작업중인 테이블 데이터 조회 등은 행이
걸릴 수 있으니 가능한 업무 중단이나 업무가 가장 적은 시간이 진행하시길 권고합니다.
또한 예기치 않은 장애 대비하여 작업전에 꼭 cold backup이나 data pump backup 받고
진행하시기 바랍니다.
(소요시간은 데이터의 양, index의 수 등에 따라 약간의 차이가 있지만
경험상 최근 하드웨어 성능상으로는 10g짜리 테이블도 10분이내로 끝납니다.)
단편화되지 않은 테이블은 할 필요가 없습니다.
추가로 위와 같은 조치는 일시적이고 효과가 미비할 수도 있습니다.
조회 성능에 가장 영향을 많이 주는 항목은 대부분 SQL문입니다.
느리다고 하는 조회 쿼리의 plan을 보고 SQL 상 튜닝 포인트가 없는지 체크해보시고
SQL문을 튜닝하시는게 가장 효과가 급니다.
GB단위면 작은 사이즈는 아닐 듯 싶습니다.
그래도 단순 텍스트가 아닌 Blob같은 데이터 형식이 있다면 무조건 많다고만 할수는 없을 듯 합니다.
각 테이블별 저장된 row를 확인해볼 필요도 있습니다.
select count(*) form 테이블명;
차이가 있으니 기능을 지원하는 것이겠죠. 다만 체감이 가능하냐는 별개의 문제일 듯 합니다.
백업 받으시고 주말에 하나의 테이블만 시도해보시고 효과가 있지는 판단해보시는 것도 방법입니다.
유지보수 업체는 그럭저럭 돌아가는 것에 굳이 손을 대고싶지는 않을 듯 합니다.