DB2 SPACE(Tablespace,Index) 이야기

원본출처 : http://my.dreamwiz.com/ibkcis/

DB2 DBA가 관리하는 항목중 TS 및 IX별 SPACE의 관리부분도 결코 무시할 수 없는 아주 아주 중요한 요소중의 하나라고 여겨집니다. 특히 스페이스사용량의 적정관리는 DBA가 챙겨(?)주지 않으면 전산자원을 아주 비효율적으로 사용할 수 도 있기 때문에 DBA라면 한번쯤은 고민해본 항목이라 생각됩니다.

적당하게 대충대충 크게 DEFINE하여 부담없이(?) 사용할 수 도 있겠지만최소의 비용으로 최대의 효과(?)를 올려야 하는 우리의 열악한(?) 전산환경에서는 꼭 짚고 넘어가야 할 문제인 것 같습니다. 더 중요한 것은 알면서 장난(?)을 치는 것은 관계없겠지만 실제 얼마만큼 사용되는지도 모르고 관리한다는 것은 DBA로써 존심이 허락하지 않잖아요...^^

각 사이트마다 나름대로의 관리요령이 있을텐데... 질문이 올라온지 꽤 지난 것 같은데 아직 답변이 없네요....ㅠ.ㅠ 평소에 저희 은행에서 관리하던 방법과 제 생각을 한번 정리해 봅니다.

볼륨별 I/O를 생각하지 않고...

단순히 스페이스량만을 가지고 생각해볼 수 있는 것은 신규로 TS나 IX를 등록할 때 어떻게 필요한량을 산출하여 적정하게 DEFINE할 것인가 입니다. 매뉴얼에 있는 계산방식을 적용하여 계산한다 하더라고 가장 중요한 신규테이블의 실제 ROW수를 파악하는 것인데 정보계는 특성상 상당부분이 실제량을 정확히 산정할 수 없다는 것에 문제가 있습니다.

사용자의 말만 믿고 알뜰하게 계산하여 등록하였지만 대부분 실패(?)하기 쉽답니다. 사용자의 어쩔 수 없는 거짓말 땜시롱...결국은 등록후의 관리가 더 중요하다는 것입니다. 그렇다면, 기왕에 등록된 것들중에 과연 적정하게 사용하고 있는지를 어떻게 파악하는가가 문제입니다. 어떤놈은 사용량이 50% 미만이고, 어떤놈은 모자라 매번 확장작업을 해주어야 하고...

확장을 해주었더니 어느날 갑자기 데이터량이 팍 삭제되어버리구....ㅠ.ㅠ 그기다가 좀더 부지런을 떨어 향후에 확장될 것을 감안하여 미리 적절하게 스페이스를 늘려주어야 하기도 하구....확장이 발생한 것을 매번 정리해주는것두 힘든데 미리 확장을 감안하여 늘려준다는 것은 참 어려운결단(?)이 있어야 하잖아요...(제 경험으로^_^).. 아까도 얘기했지만 늘려줄 때도 기양 팍 늘려주면 좋을텐데 그것도 여의치않으니 적정량을 계산한다는 것이 머리아프고... 어쨌던 직장에서 짤리지 않고 내가 맡고 있는일에 최선을 다 하려면 이놈들을 요령것 관리해야 하는데... 제일 쉽게 생각할 수 있는 것은 별도의 TOOL를 구입하여 활용하는 것인데.... DASD와 관련하여 여러제품들이 있겠으나 괜히(?)가격만 비싼 것같구...싸더라도 구입해주지도않구...

구입해준다해도 괜히 잘모르는사람들에게 좋은일만 시키는 것같아 기분나쁘고... 그 다음에 생각할 수 있는 것이 우리가 마르고 닳도록 상시애용하는 CATALOG 테이블의 정보들을 활용하는 것인데...실제사용량을 파악하는데는 일부 미흡하고, 최신정보를 볼려면 매번 RUNSTATS작업을 해주어야 하는데... 이또한 여의치 않구요. 그래서 생각한 것이 VSAM LISTCAT를 통한 HI-U-RBA값을 활용하는 것입니다.

(참고 : RBA값을 실린더 단위로 환산하려면 => CYLINDER = RBA값 / 737,280 )

건건이 LISTCAT 작업을 할 수 없으니까 관리하는 모든 D/S의 LISTCAT를 일괄적으로 출력 (통상 정보계용 DB는 별도의 USER CATALOG를 사용하고있잖아요)SAM파일로 만들어 놓고 D/S별 사용량정보를 출력하는 배치프로그램을 하나 개발하면 데이셋별 실제사용량을 파악하는 것은 문제가 없는 것 같습니다. 물론 데이터셋별로 일자별로 실제사용량을 관리하는 DB2 테이블을 만들어 HISTORY정보도 관리하구요. TS나 IX의 실제 사용량을 DB로 갖고 있다면 적정량을 스페이스관리뿐만아니라 BACK_UP테이프의 적정사용여부(실제테이프용량만큼 효과적으로사용하고 있는지 여부)와 또 하나 중요한 것은 재편성작업시 WORK SPACE 지정를 효과적으로 사용할 수 있다는 것입니다.

양이 적은 것들은 작게, 양이 많은 것은 크게 WORK SPACE를 지정하여 휴일등 동시에 여러 JOB SUB시 꼭 필요하다는 것입니다. 어자피 WORK 볼륨도 한정되어 있잖아요. 저희은행은 재편성대상선정과 수행작업을 배치프로그램으로 개발하여 일괄적으로 수행하고 있답니다.

같은의미로 저희은행에서는 테이블별 실제ROW수를 별도로 관리하고도 있답니다. 테이블별로 실제 ROW수를 매일 특정시간대에 한번씩 COUNT(CATALOG정보를사용하지 않음)하여 매일,매월,매년 형식으로 테이블을 만들어 테이블별 ROW수를 관리하여 테이블별ROW수의 변천사(?)를 관리한답니다.

계속 증가만 되는지, 특정주기로 생성되었다 삭제되었다 하는지, 갑자기 테이터량이 증가하거나 줄어들었는지 등 테이블별ROW의 사이클를 파악하는데는 아주 따봉~...^^ 특히나 TS의 RECORY작업시 확인용으로도 활용한답니다. 과거로 복구했을시 그 당시의 ROW수를 확인해 보는 것이지요. UPDATE는 확인이 안되지만... 또한 테이블별 레코드길이를 곱하여 현재량(실제는+알파하여)을 파악하는데 참고로도 활용하구요.

추가로 당행에서는 OMEGAMON II FOR DB2 라는 모니터링 TOOL를 사용하고 있습니다. 이 툴에는 모니터링 항목중에는 OBJECT ANALYSIS 부분이 있는데 그 곳에서 OBJECT ALLOCATIONS정보, OBJECT ACTIVITY정보, VOLUME ACTIVITY정보, EXTEND ACTIVITY정보 등을 REALTIME으로 참고하고 있습니다. 아쉬운 것은 BATCH REPRORT는 제공되지 않습니다.

주식회사 캔들에서는 별도의 DASD TOOL를 가지고 있다보니 그런 것 같아요... OBJECT 및 DASD의 현재의 사용정보를 파악하는데 아주많은 도움을 받고 있답니다. 이상 생각나는대로 한번 적어봤습니다.

별내용도 없으면서 글이 너무 길어 짜증이나 나지 않으셨는지...그렇다면 지송... 끝까지 읽어주심을 감사드리며 조금이나마 힌트라도 되었으면 합니다.

좀더 쉽고 좀더편한,새로운 방법이 있으시면 이곳을 통하여 꼭 공유시켜주세용...

그럼....