반응형
지원하는 모 사이트에 다른일로 방문을 하였는데 , 마침 그날 오전에 DB2 에 장애가 발생하였었고 , 이로 인하여 서버를 Restart 한 상황이었다. 그런데 문제는 서버를 Restart 하였음에도 DB가 아직 정상적으로 동작을 하지 않는다는 것이였다.
db2diag 로그파일에는 "DISK FULL" 메세지만 자꾸 출력이 되고 있는 상황이다.
보통 DISK FULL 메세지는 archive log 파티션이 Full 이 나거나 Active Log 디렉토리 쪽에 Full이 나는 경우다.
Secondary Log를 사용하려고 하는데 로그파일을 생성 할 수 없어서 Disk Full 메세지가 자꾸 출력이 되고 있었다.
또한 Active Log를 사용하고 있는 Application을 찾아서 Force Application을 수행하려고 하여도 appl id가 0 으로 보여서 Kill도 할 수 없는 상황임.
하는 수 없이 급하게 Active Log쪽에 Disk를 추가적으로 붙이니 Disk Full은 발생은 하지 않으나, 근본적인 Log를 잡고 있는 Transaction은 확인이 안된다.
LIST INDOUBT TRANSACTIONS 명령을 수행해도 트랜잭션이 보이지 않으며 , 데이터 베이스 스냅샷을 떠 봐도 Number of indoubt transactions 값은 0 으로 나옴.
이 대로 그냥 두면 Secondary 로그 까지 다 써서 이제는 Log Full이 발생할 상황이라 . 서버를 다시 리부팅 함.
서버가 리부팅 된 후 에도 지속적으로 로그가 증가 함.
그러나 이제는 LIST INDOUBT TRANSACTIONS 명령을 수행하면 Transaction이 확인이 됨.
해당 트랜잭션들을 처리 하여 로그 사용이 더 이상 증가 되는 것을 막을 수 있었음.
위와 같은 상황이라 텔넷으로 서버에 접속해서 확인해 볼수도 없는 상황이고, 또 간단한 용무로 방문을 하였던 터라 노트북도 가지고 들어가지 않았고 , 가장 근본적인 가장 오래된 트랜잭션을 가리키는 지표명이 생각이 안났다 ㅠㅠ;
데이터 베이스 스냅샷을 뜨면 Appl id holding the oldest transaction 라는 부분이 있다. 이 부분이 현재 로그파일을 사용하고 있는 가장 오래된 세션의 Application ID를 알려 주는 부분인데 이 부분이 생각이 나질 않았다.
이 부분만 생각이 났었어도 장애처리하는데 도움을 더 빨리 줄 수 있었는데 , 또 Application ID가 0으로 나올때 저 값은 어떻게 나왔는지도 확인을 해 볼수 있고 ... 암튼 이번은 좀 많이 아쉬웠었다.
아마 처음 서버를 리부팅 했을때 로그가 늘어나야 하는데 정상적으로 늘어나지 못하는 상황이라서 DB2 버그인지 , 암튼 Application ID가 0으로 보였던 것 같다. 마지막 리붓 후에 application id가 그나마 정상적으로 보였으니 처리가 되었지 , 그때도 보이질 않았었다면 ... 휴 ...
db2diag 로그파일에는 "DISK FULL" 메세지만 자꾸 출력이 되고 있는 상황이다.
보통 DISK FULL 메세지는 archive log 파티션이 Full 이 나거나 Active Log 디렉토리 쪽에 Full이 나는 경우다.
Secondary Log를 사용하려고 하는데 로그파일을 생성 할 수 없어서 Disk Full 메세지가 자꾸 출력이 되고 있었다.
또한 Active Log를 사용하고 있는 Application을 찾아서 Force Application을 수행하려고 하여도 appl id가 0 으로 보여서 Kill도 할 수 없는 상황임.
하는 수 없이 급하게 Active Log쪽에 Disk를 추가적으로 붙이니 Disk Full은 발생은 하지 않으나, 근본적인 Log를 잡고 있는 Transaction은 확인이 안된다.
LIST INDOUBT TRANSACTIONS 명령을 수행해도 트랜잭션이 보이지 않으며 , 데이터 베이스 스냅샷을 떠 봐도 Number of indoubt transactions 값은 0 으로 나옴.
이 대로 그냥 두면 Secondary 로그 까지 다 써서 이제는 Log Full이 발생할 상황이라 . 서버를 다시 리부팅 함.
서버가 리부팅 된 후 에도 지속적으로 로그가 증가 함.
그러나 이제는 LIST INDOUBT TRANSACTIONS 명령을 수행하면 Transaction이 확인이 됨.
해당 트랜잭션들을 처리 하여 로그 사용이 더 이상 증가 되는 것을 막을 수 있었음.
위와 같은 상황이라 텔넷으로 서버에 접속해서 확인해 볼수도 없는 상황이고, 또 간단한 용무로 방문을 하였던 터라 노트북도 가지고 들어가지 않았고 , 가장 근본적인 가장 오래된 트랜잭션을 가리키는 지표명이 생각이 안났다 ㅠㅠ;
데이터 베이스 스냅샷을 뜨면 Appl id holding the oldest transaction 라는 부분이 있다. 이 부분이 현재 로그파일을 사용하고 있는 가장 오래된 세션의 Application ID를 알려 주는 부분인데 이 부분이 생각이 나질 않았다.
이 부분만 생각이 났었어도 장애처리하는데 도움을 더 빨리 줄 수 있었는데 , 또 Application ID가 0으로 나올때 저 값은 어떻게 나왔는지도 확인을 해 볼수 있고 ... 암튼 이번은 좀 많이 아쉬웠었다.
아마 처음 서버를 리부팅 했을때 로그가 늘어나야 하는데 정상적으로 늘어나지 못하는 상황이라서 DB2 버그인지 , 암튼 Application ID가 0으로 보였던 것 같다. 마지막 리붓 후에 application id가 그나마 정상적으로 보였으니 처리가 되었지 , 그때도 보이질 않았었다면 ... 휴 ...
반응형