Tuxedo 운영 중 발생빈도가 높은 에러 및 조치사항

1. Tuxedo Tip

 

1) BBL에 부하가 발생하는 경우 확인 해야 한 것

 - TMIB 서비스를 과도하게 사용하는지 확인

 - 모니터링 쉘, 데몬 프로그램에 대하여 주기, 방식, pclt를 사용하는지 확인

(일정 주기로 Q 정도만 나머지는 기동시 한번만)

 - 모니터링 데몬 프로그램을 Native 클라이언트가 아닌 Workstation 클라이언트로 되어 있는지 ?

 - 모니터링 데몬 프로그램이 /T에 접속하는 방식

(매번 하는지 아니면 처음 기동할 때 한번 하는지 ?)

 - WSH의 x 파라미터

(WSH 당 관리할 수 있는 클라이언트 잇는 x 파라미터 값을 증가하여 WSH 수를 줄임)

 

2) Tuxedo/Q에서 TMQFORWARD 서버를 사용할 경우 반드시 QMCONFIG에 Device가 지정되어야 한다.

3) Domain G/W 설정 시 H/W가 다르거나 웹 환경인 경우 MTYPE를 설정하지 않는다.

4) 서비스에서 자산이 속한 SVRID를 알수 있는 방법

   tpsvrinit 함수에서 getopt함수를 이용하여 "i"의 option값을 알아 낸 뒤 전역변수에 보관하여 사용하는 방법

5) Workstation Handler level에서 거래로그를 남기는 방법

   tmtypesw.c에 거래로그를 남길 수 있도록 Customizing한 다음 buildwsh로 User WSH를 생성하여 사용하면 됨.

6) Tuxedo 8.0 이상 Version 설치시 /tmp 및 설치 디렉토리에 대한 Disk space 확인 요망

    취소 400MB이상 요구(반드시 확인)

7) Tuxedo 서버 프로세스가 기동 중 멈춰서 있는 현상 발생.

   Database가 기동되어 있지 않은 경우에 발생.

8) Tux 6.x 클라이언트가 Tux 7.x 서버로 접속할 경우

   관련 서버의 CLOPT에 '-t' option이 필요

   주의) -- 앞쪽에 설정 요망

9) Tux 7.x 클라이언트가 6.x 서버로 접속할 경우

   환경변수 'WSALLOWPRE71=Y'가 필요

10) Maximum action table size

    내부적으로 10,000으로 되어 있는데, Tux 7.1 이상 부터는 환경변수 TUX_GW_ACTMAX를 통하여 재설정 가능

11) MP mode에서 tmadmin의 'psr, psc' 명령어 수행 했을 때 수행 횟수를 알 수 있는 방법

    tmadmin에서 'd -m LMID' 명령어를 수행한 후 'psr, psc' 명령어 수행하면 됨

12) Oracle-3113 에러 시 자동 재접속 방법(XA 모드에 해당)

    환경변수 'TUXWA4ORACLE=1'가 필요

13) Tux 장비가 Shutdown 되었을 때, tpinit connection timeout 조정

    네트워크 연결에 실패했을 때 재시도하는 횟수와 관련된 파라미터는 다음과 같이 Windows registry를 수정한다.

    - Windows NT와 2000에서

      TcpMaxConnectRetransmissions

    - Windows 98에서

      MaxConnectRetries

 

    연결된 후에 데이터를 주고받을 때의 timeout에 관련된 파라미터

    - Windows NT와 2000에서

      MaxConnectRetransmissions와 InitialRtt

    - Windows 98에서

      MaxDataRetries

14) SVCTIMEOUT 발생 시 SIGKILL을 보내기 전에 SIGTERM을 보내어 사용자가 좀 안정적인 종료 처리를 할 수 있는 방법

    환경변수 'TM_SVCTIMEOUT_SIGTERM=Y'가 필요

15) local domain과 remote domain간의 connection 시점

    - on_DEMAND     : remote domain에 있는 service 요청 시 또는 dmadmin 명령을 통해 connection이 이루어진다.

    - on_STARTUP    : domain gateway가 start되면 connection이 이루어진다.

    - INCOMING_ONLY : remote domain에서 local domain에 있는 service 요청 시 또는 dmadmin 명령을 통해 connection이 이루어진다.

16) remote domain과 connection되어 있지 않은 상태에서 자동으로 retry 시도

    - on_DEMAND     : retry 하지 않는다.

    - on_STARTUP    : 자동으로 retry 시도

    - INCOMING_ONLY : retry 하지 않는다.

17) remote domain과 connection되어 있지 않은 상태에서 remote service 상태

    - on_DEMAND     : available 한 상태로 remote domain에 service 호출 후 에러 발생

(Fail-over 안됨)

- on_STARTUP    : suspend 상태로 service 호출 시 바로 에러 발생(Fail-over 가능)

    - INCOMING_ONLY : suspend 상태로 service 호출 시 바로 에러 발생

18) WSNAT_CAT:1043 에러가 발생했을 때 클라이언트가 요청한 서비스 이름을 표시하는 방법

    WSH의 환경변수에 'TMULOGUSINGSERVICENAME=Y'가 필요

19) Domain간 connection 시 remote domain의 IP check

    환경변수에 'GW_VALIDATE_HOST=YES'가 필요

20) 비정상적인 프로세스로 인해 tmshutdown 명령이 프로세스의 종료를 기다리느라 다른 프로세스의 종료를 수행하지 못하는 경우

    환경변수에 'TM_SHUTDOWNTIMEOUT=0~65535'가 필요

21) 서버 프로세스 부팅 시에 비정상적인 상황이 발생하여 프로세스가 Hang 상태에 빠지는 경우

    환경변수에 'TM_BOOTTIMEOUT=0~65535'가 필요('TM_BOOTTIMEOUTKILL=0~65535', 'TM_BOOTPRESUMEDFAIL=Y')

22) 서버 프로세스 restart 시에 비정상적인 상황이 발생하여 프로세스가 Hang 상태에 빠지는 경우

    환경변수에 'TM_RESTARTSRVTIMEOUT=0~65535'가 필요('TM_RESTARTSRVTIMEOUTKILL=0~65535')

23) Tuxedo 프로세스가 BB에서 작업하고 있을 때 SIGKILL이 내포된 명령어를 사용하여 프로세스를 강제 종료하는 경우에 BB의 데이터가 훼손을 방지할 수 있는 방법

    환경변수에 'TM_KIL_WITH_BBLOCK=Y'가 필요

24) CLOPT : 명령어 라인상의 옵션을 넘기기 위한 매개변수

    ▷ OPTION

       -A  : 서버에 포함된 모든 서비스를 실행

       --  :  옵션간의 구분을 위한 기호

       -n  :  WSL이 상주하는 네트워크 Address

       -w  :  WSL이 기동시킬 WorkStation Handler의 명칭

       -m  :  Minimum WSH 수

       -M  :  Maximum WSH 수

       -x  :  하나의 WSH에 접속 가능한 클라이언트수

       -T  :  WSL 타임아웃 시간

       -I  :  클라이언트 타임아웃 시간

       -r  :  Report를 작성한다

       -o  :  표준출력 메세지를 file.out 형태로 저장

25) Oracle에 XA를 사용하고 있는 환경에서 application server의 수행 시간 등이 길어져 Transaction time out이 발생한 경우 TMS에 큐잉이 되는 경우가 있다.

     Oracle의 SesWt를 조정할 필요가 있다.

     SesWt는 다른 session에 의해 사용 중인 transaction branch를 얼마나 기다릴 것인가를 초단위로 지정하기 위한 parameter로 default 값은 60(초)이다.

     application server가 XA를 사용하는 경우 서비스가 시작되면 xa_start()가 수행되고 서비스가 끝나면 xa_end()가 수행된다. 수행 시간이 길어져 Transaction time out이 발생하게 되면 TMS에 의해 xa_rollback() 요청이 있게 되는데, 이때 Oracle은 xa_end()가 수행되지 않은 session에 대해 SesWt에 지정된 시간만큼 xa_rollback()을 wait한다.

     결과적으로 Oracle로부터 xa_rollback()의 return을 받지 못하므로 TMS에 큐잉이 발생한다.

     SesWt은 Oracle에서 xa_open string의 한 field로 제공하는 것으로, 아래와 같이 ubbconfig의 OPENINFO에서 설정할 수 있다.

     OPENINFO="Oracle_XA:Oracle_XA+Acc=P/scott/tiger+SesTm=180+SesWt=1+SqlNet=ORA920"

26) TPEBLOCK 발생시 psc로 해당 서버의 서비스들의 상태를 확인해 보니, susp로 되어 있씀

    susp가 발생하는 경우는 CONNECTION_POLICY=ON_STARTUP 이면서 REMOTE SERVICES절에 등록되어 있는 경우(도메인이 끊어진 경우) IPC 자원이 부족한 경우(Message queue, Semaphore)이다.

 

 

2. ISSUE

 

이슈 : XA 서비스를 non-XA 모드로 호출할 때, etc.

       1.XA 서비스를 non-XA 모드로 호출할 때

         1) OPENINFO에 NoLocal=true가 설정되어 있을 때

            - 일단 tpbegin()을 호출하지 않았기 때문에 Transaction Context가 아니라서 xa_start()는 호출되지 않는다.

            - 그런데, NoLocal=true가 설정되어 있으면 SQL 수행시 ORA-00155: cannot perform work outside of global transaction이 발생한다.

            - 따라서 SQL error만 제대로 체크하는 루틴이 있으면 문제없다.

         2) OPENINFO에 NoLocal=true가 설정되어 있지 않을 때

            - 위와 마찬가지로 xa_start()는 호출되지 않는다.

            - SQL은 Local transaction으로 수행된다.

            - 위에서의 Local transaction에 대해서 COMMIT/ROLLBACK 명령이 없으므로

            - 이 상태에서 XA 모드로 서비스를 호출하게 되면 LIBTUX_CAT:481: ERROR: Service xa_start returned -9 발생

            - 이 경우에는 서버를 Rebooting하여야 한다.

       2.non-XA 서비스를 XA 모드로 호출할 때

         1) tpcall() 시에 에러가 발생하며, tperrno=14(TPETRAN)이다.

         2) 이 경우에는 tpcall()의 flag에 TPNOTRAN을 설정하거나 tpbegin()을 호출하지 않은 상태에서 tpcall()을 수행하여야 한다.

       3.xa_start() returned -9

         1) 위의 경우에서도 보인 바와 같이 Transaction이 Local transaction으로 진입한 이후에

         2) 정상적인 COMMIT/ROLLBACK 명령을 수행하지 않고

         3) XA 모드로 다시 서비스를 호출하면 발생한다.

         4) 서버를 Rebooting하여야 한다.

         5) 위의 경우처럼 XA 서비스를 non-XA 모드로 호출하였다가 XA 모드로 호출하는 경우라든가

         6) Timeout 등에 의해 xa Session이 끊어진 이후에 에러 처리를 제대로 하지 않아서

         7) Local Transaction으로 진입한 경우가 있다.

 

이슈 : Caching된 Field table의 Reload 방법

       FML 함수에서 사용되는 Field table은 보다 빠른 접근을 위해서 메모리 상에 Caching이 되게 된다. 따라서, AP가 떠 있는 상태에서 해당 파일의 내용을 변경 하더라도 바로 반영이 되지 않는다.

        일반적으로 Field table은 거의 변경하지 않기 때문에 큰 문제가 되지는 않지만, 만일 한 Process 내에서 2개의 서로 다른 Tuxedo System으로 접속을 하고, 그 두 시스템에서 사용하는 Field table에 충돌이 있는 경우에는 이를 해결할 방법이 없다.

조치 : Tuxedo에서는 Field table을 위한 Cache를 Unload하기 위한 함수를 제공한다. FML을 위한 Cache는 ID를 Name으로 맵핑하기 위한 테이블이 존재한다.

        먼저, ID를 Name으로 맵핑하는 테이블을 Unload하기 위한 함수는

          (void)Fidnm_unload(void)

          (void)Fidnm_unload32(void)

        그리고, Name을 ID로 맵핑하는 테이블을 Unload하기 위해서는

          (void)Fnmid_unload(void)

          (void)Fnmid_unload32(void)

 

이슈 : FML32 사용상의 주의점

       1.보다 많은 Field number를 사용할 수 있고( < 33554431)

       2.버퍼 크기의 제한을 덜 받는다.(최대 2GB)

조치 : FML32를 사용할 경우에 사용할 수 있는 Field number는 증가하지만, Data Dependent Routing을 위해 사용되는 필드의 Number는 반드시 8191 이하이어야 한다. 따라서, 만일 특정 필드가 Data Dependent Routing을 위해서 사용될 것이라면 이의 필드 Number는 8191 이하로 설정해야 한다.

        FML32를 사용하더라도 Windows 3.1에서는 64KB로 버퍼의 크기가 제한된다. 따라서, 혹시라도 Windows 3.1을 같이 사용하고 있는 환경에서는 이 제한을 받게 된다.

        많은 필드를 한 버퍼에 넣을 경우에 속도 문제를 고려한다면 Fchg32() 보다는 Fappend32()를 사용하는 것이 바람직하다.

 

이슈 : 특정 서버가 비정상 종료된 상태에서 "tmadmin" 상의 "psr"에 의한 서버의 상태가 계속적으로 Cleaning 혹은 Restarting 상태로 남아 있음.

조치 : BB의 Cleaning/Restarting 상태는 BBL이 해당 서버의 비정상 종료를 감지하고, cleanupsrv/restartsrv를 수행하고 있는 상태를 의미한다.

        이 작업은 일반적으로 몇 초 내에 종결되는 작업이다. 이 상태가 오래도록 지속되는 경우 다음 2가지로 나누어 볼 수 있다.

        1.cleaning/restarting 작업에 지연요소 발생

          서버 restarting의 경우에 DB 접속과 같은 작업이 이루어진다. 그런데 DB 접속이 지연되는 경우에는 cleanupsrv/restartsrv가 해당 작업을 종료할 수 없다. 따라서, 그 상태가 오래도록 지속되게 된다. 이 경우 해당 지연 요소를 먼저 제거해 주어야 한다.

        2.PID 재사용에 의한 문제

          특히, AIX와 같이 PID 재사용이 많은 경우에 발생하는 문제로 BBL이 비정상 종료된 프로세스를 정리하기 전에 해당 PID를 다른 프로세스가 차지하게 되는 경우를 말한다. 이 경우 cleanupsrv/restartsrv는 마치 해당 프로그램이 동작 중인 것으로 판단하여 해당 상태에 대한 update를 하지 않게 된다.

          이 때에는 "tmadmin"의 "psr" 명령을 verbose 모드로 수행하여 그 PID를 확인하고 종료시킨 후에 cleanupsrv/restartsrv를 수행시켜주면 된다.

          위 PID 재사용에 의한 문제는 서버 뿐만 아니라, "tmshutdown"과 같은 Native client의 경우에는 발생할 수 있으면, 이경우에는 "pclt" 명령에서 PID를 확인할 수 있다.

 

 이슈 : TIME_WAIT 상태시간 줄이기

        TIME_WAIT 상태는 정상적인 종료 과정에서 거치게 되는 과정으로 마지막 ACK 신호를 잃어 버린 경우에 재 전송하기 위한 상태이다.

        Client/Server 환경에서는 주로 Connection-Oriented 형식으로 사용하기 때문에 이 상태에 머무르는 소켓의 개수가 많지 않지만, Connectionless 형식을 사용하는

        HTTP 환경에서는 부하에 비례하여 생기게 된다. 따라서, 부하가 많은 경우에는 이 상태에 잔류하는 소켓이 많아지게 되어 File Descriptor 개수 제한에 걸리게 된다.

조치 : 위와 같이 TIME_WAIT에 잔류하는 소켓의 개수를 줄이기 위해서는 그 잔류시간을 줄여주는 것이 바람직하다.

        일반적으로 Unix 메신에서는 "root" 권한을 가진 사용자가 다음과 같이 "ndd" 명령을 사용하여 조회/변경이 가능하다.

          조회시 : ndd       /dec/tcp tcp_time_wait_interval

          변경시 : ndd-set   /dec/tcp tcp_time_wait_interval <value>

        여기서 <value>에 해당하는 값은 milli-second 단위이다.

        그리고, Windows 환경에서는 아래의 "TcpTimedWaitDelay" 값을 Registry에서 설정하면 된다.

        --------------------------------------------------------------------------------------

        TcpTimedWaitDelay (new in Windows NT version 3.51 SP5 and later)

        Key:Tcpip\Parameters

        Value Type: REG_DWORD - Time in seconds

        Valid Range: 30-300 (decimal)

        Default: 0xF0 (240 decimal)

        --------------------------------------------------------------------------------------

        Windows 환경에서 자세한 적용 절차는 다음 URL을 참조(http://support.microsoft.com/support/kb/articles/Q120/6/42.asp)

 

이슈 : FireWall을 위한 Tuxedo 구성

        FireWall은 네트워크 상에서 패킷의 전송을 제한함으로써 허가되지 않은 사용자의 접근을 방지하는 일을 한다.

       FireWall은 크게 지정된 포트를 통한 데이터 전송 만을 걸러주는 패킷 필터링(Packet Filtering) 방식과 외부에서 들어오는 패킷을 검사하여 허가된 패킷을 마치 자신이 보내는 것과 같이 재 전송하는 프록시 방식(Proxy)으로 나뉘어 진다.(프록시 방식은 NAT-Network Address Translation-방식이라고도 부른다.)

       이런 FireWall이 클라이언트와 서버 사이에 존재할 경우에는 Tuxedo용 패킷이 FireWall을 통과할 수 있도록 하기 위한 설정이 필요하다.

조치 : 클라이언트와의 접속을 관리하는 프로세스인 WSL에는 FireWall을 위한 두 가지 옵션이 존재한다.

      먼저, 지정된 포트만을 사용해야 하는 패킷 필터링 방식을 지원하기 위해서는 WSH가 사용하는 포트를 제한하는 -p(min. Port), -P(max. Port) 옵션을 사용하면 된다.

      예를 들어, FireWall에서 허용된 서버의 Port가 20000부터 20050번 까지라면 WSL을 다음과 같이 정의할 수 있다.

      예) CLOPT="-A -- -n //server:20000 -p 20001 -P 20050"

      그리고, 프록시 방식의 FireWall의 경우는 클라이언트로 보내지는 접속할 WSH의 IP Address를 지정하는 -H 옵션을 추가하여야 한다.

      예를 들어, FireWall의 외부 IP가 ppp.xxx.yyy.zzz이고, 허용된 포트가 20000에서 20050이라면 다음과 같이 설정할 수 있다.

      예) CLOPT="-A -- -n //server:20000 -p 20001 -P 20050 -H //ppp.xxx.yyy.zzz:20000"

 

이슈 : Tuxedo 6.x와 7.x의 연동성

       Tuxedo 7.x 버젼부터는 Thread 기능 지원 등을 포함하여 많은 부분이 변경되었다.

       따라서, 이번 버젼(6.x 이하)과 상호 연동을 하기 위해서는 몇 가지 작업이 필요하다.

조치 : 상호 연동성 문제는 다음의 2가지 경우로 나눌 수가 있다.

       1) 6.x 클라이언트가 7.x 서버로 접속할 경우

          관련 서버의 CLOPT에 "t" option이 필요(주의: -- 앞쪽에 설정 요)

       2) 7.x 클라이언트가 6.x 서버로 접속할 경우

          환경변수 WSALLOWERE71=Y가 필요

 

이슈 : Domain config의 BLOCKTIME과 Transaction timeout의 관계

        Domain간의 Transaction 처리 시에 설정된 Transaction timeout보다 먼저 TPETIME 에러가 발생하는 경우가 있다.

       그 원인은 보통 Domain config 상에 설정된 BLOCKTIME이 먼저 적용되었기 때문이다.

       Ubbconfig 상에 설정된 BLOCKTIME은 Transaction timeout이 설정되어 있으면 무시되므로 Domain config의 경우도 그런 것으로 짐작하는 경우가 많다(실제 Tuxedo manual 상에도 그렇게 기술되어 있으며 현재 수정되어야 할 사항임).

       그러나, 실상은 이 두가지(Transaction Timeout, BLOCKTIME in Domain config) 중에 짧은 것이 먼저 영향을 준다.

조치 : Transaction과 관련된 Domain config 설정 시 BLOCKTIME을 해당 Gateway를 통해 발생될 Transaction 중 최대로 오래 걸리는 것을 고려하여 그 보다 크게 설정하여야 할 것으로 보임.

 

이슈 : GTT full과 MAXTRANTIME

       Tuxedo MP, Domain model 사용 시 Aborted된 Transaction이 GTT(Global Transaction Table)에서 Clear 되는데 경우에 따라 Transaction timeout까지 소요될 수가 있다.

       따라서, Timeout을 불필요하게 크게 설정(예를 들어, Batch 작업관련 Service 요청 시 tpbegin에서 Transaction timeout을 0으로 설정(System의 unsigned long의 최대값으로 약 20억초)하는 경우가 간혹 있슴)하면 위와 같이 Aborted된 Transaction들이 누적되어 ubbconfig에서 설정한 MAXGTT값을 초과, GTT full을 유발할 수 있다.

        이를 방지하기 위해서는 Application에서 tpbegin시 설정한 Transaction timeout을 적절히 작은 값으로 변경하면 되나 code 수정에 상당히 많은 시간이 소요될 수 있으므로 빠른 조치를 위해 MAXTRANTIME이라는 Parameter를 사용하여 일괄적으로 제어할 수가 있다.

조치 : MAXTRANTIME은 Tuxedo 8.1에서 새롭게 추가된 Parameter이며 Tuxedo 6.5의 경우에는 patch(377.CR091218 MAXTRANTIME backport)를 적용하면 사용이 가능하다.

 

 

3. CMDTUX 관련

 

CMDTUX_CAT: 944

메시지내용: WARN: Can't Shutdown server (GRP9827/151)

원    인 :  그룹이 GRP9827이고 id가 151인 서버를 shutdown 할 수 없다. 이 프로세스가 이미 죽어 있거나, shutdown 메시지에 대한 응답이 없거나, 메시지 send 그 자체가 실패 했음을 의미한다.

해결방법 : 서버 프로세스가 존재하는 machine에 대한 네트워크 partition을 조사하고,remote machine의 서버를 "kill -9"를 이용하여 죽이고, IPC 자원을 clear 하여야 한다. 이 상황에서 정상적인 shutdown은 사실상 어렵다.

 

CMDTUX_CAT: 1380

메시지내용: ERROR: Message queue blocking prevented delivery, Qaddr=67585

원    인 : Unix message queue 가 blocking 상태이기 때문에 BRIDGE 프로세스가 네트워크로부터 받은 메시지를 전달할 수 없을 때 나타나는 메시지. Queue가 full 상태인 프로세스는 tmadmin의 psr 명령어를 verbose mode로 실행시켰을 때 qaddress가 메시지의 Qaddr가 일치하는 프로세스이다. 또다른 메시지 큐의 상태 확인 방법은 ipcs -aq 를 이용하는 것이다.

해결방법 :  (1) 메시지 큐와 관련된 kernel parameter인 MSGMNB, MSGSSZ, MSGSEG, MSGMAX를 살펴 적절한 값으로 되어 있는지 확인한다.

Machine에서 현재의 Kernel Parameter값 확인하는 방법 :

        $> kmtune

(2) 해당 machine에 서버 프로세스를 더 띄운다.

(3) MSSQ(Multi-server single queue) set 당 서버의 수를 감소시킨다.

(4) machine의 오버헤드를 유발시키는 performance 문제를 점검하고 필요한 경우 DB 부분의 tunning을 요청한다.

(5) 해당 machine에 보내지는 일을 줄이기 위해서 구성 파일의 load factor을 조절한다.

(6) Error 발생 시점에서 System Over Head, 혹은 Network Overhead 가 발생 할 만한 의심이 가는 다른 작업을 수행하는 Client가 있는지 확인한다.　

 

 

4. LIBTUX 관련

LIBTUX_CAT: 212

메시지내용 : ERROR: tmbbclean failed, message send/receive error

원    인 :  local bulletin board를 clear 하고 status를 점검하기 위해 BBL에게 메시지를 보내려고 한 시도가 실패

해결방법 :  이전의 메시지를 살펴보고, message queue가 blocking 상태에 있는지를 점검한다. 만약 메시지 queue가 blocking 상태에 있다면 시스템에 load가 많이 걸리는 것이므로 Kernel parameter를 적절히 튜닝해야 한다.

 

LIBTUX_CAT : 217

메시지 내용 : WARN: pid=xxxxx died leaving BB locked; cleaning up

원    인 : (1)특정 프로세스가 BB에 lock을 잡은 상태로 down.

           (2)machine에서 NETLOAD 값이 32767을 넘는 경우 remote machine 으로 tpcall 또는 tpacall 하는 경우 발생

해결방법 : 해당 프로세스의 프로그램을 조사하여 오류 부분을 수정한다.

 

LIBTUX_CAT: 223

메시지내용 : WARN: Duplicate server

원    인 :  이 서버가 떠 있는 상태임에도 불구하고 또다시 booting을 시도했다는 메시지

해결방법 :  booting 하고자하는 서버가 떠 있는 것이 맞는지를 확인한다. 만약 그 서버가 비정상적으로 죽었거나 hang이 걸려 있으면 (즉 멈춘상태), 이 프로세스는 kill 로 죽여야 한다. 그리고 다시 이 서버를 부팅시키기 전에 bulletin board 에서 이 서버에 대한 정보를 지우기 위한 여유 시간을 주어야 한다. (SCANUNIT * SANITYSCAN + alpha )

 

LIBTUX_CAT: 296,319 (BBL booting failed)

(1) 메시지 내용

LIBTUX_CAT:296: ERROR: _tlog_open: _gp_tblopen: VTOC not initialized

LIBTUX_CAT:319: ERROR: Log start cannot open tlog

원    인: TLOG화일 미생성

해결방법: TLOG 화일 생성

 

LIBTUX_CAT:328

메시지내용 : ERRR: No space in Bulletin Board for Service table

원    인 :  Bulletin Board 내의 Service table이 꽉 차 있기 때문에 이 table에 대하여 free entry를 할당하려는 시도가 실패했슴을 의미한다.

해결방법 :  service table의 사이즈를 늘려주기 위해 어플리케이션을 재구성한다. TUXEDO 구성화일에서 MAXSERVICES의 수를 늘려준다.

 

LIBTUX_CAT: 334

메시지내용 : ERROR: No BBL

원    인 :  Bulletin Board가 없이 프로그램을 booting 시켰을 때 나타나는 메시지임.

해결방법 : 현재의 TUXEDO system 관리자와 관련된 IPC 자원을 clear 시키고, 어플리케이션을 다시 reboot 시킨다.

 

LIBTUX_CAT: 358

메시지내용 : ERROR: Reatched UNIX limit on semaphore ids

원    인 : 시스템 전체에 허용된 semaphore의 최대 한계를 벗어나기 때문에 BBL이 더 이상 semaphore id를 만들지 못한다는 메시지

해결방법 : UNIX system semaphore의 수를 늘려준다.

 

LIBTUX_CAT: 430

메시지내용 : ERROR: Application rejects shutdown request

원    인 : APPlication 이 shutdown 요청을 거부했을 때 나타나는 메시지. BBL, TMS 등이 shutdown 될 수 없는 상태에 있음을 의미한다.

해결방법 :  위와 같은 경우 강제로 shutdown 하고 싶을 경우에는 다음과 같이 -w option을 사용하면 된다.

$ tmshutdown -s -w TMS_ORA920

 

LIBTUX_CAT:466 ( TMS_ORA920 booting failed )

(1) 메시지 내용

TMS_ORA920.2196: LIBTUX_CAT:466: ERROR: tpopen TPERMERR xa_open returned XAER_RMERR

원인 : (1) ORACLE_SID 값이 잘못 세팅되어 있음

(2) $ORACLE_HOME/bin에 있는 oracle, oracle0가 set user 비트가 세트되지 않음

(3) ubb file의 OPENINFO에 oracle user/passwd 가 오류

(4) tuxedo login id로 sqlplus를 실행하지 못함

(5) OPENINFO의 oracle user/passwd 가 oracle 에 대한 권한 부여가 되어 있지 않다

해결방법

(1) ORACLE_SID를 맞게 세트한다.(환경변수 세트 파일, ENVFILE 조사)

(2) oracle, oracle0 의 파일 모드를 4755로 세트한다.

(3) ubb file의 OPENINFO의 oracle user/passwd를 맞게 세트한다.

(4) tuxedo login id에서 OPENINFO의 user/passwd를 가지고 sqlplus를 수행할 수 있도록 한다.

(5) OPENINFO의 oracle user/passwd 가 oracle 에 대한 권한 부여를 한다

grant resource,dba,connect to scott identified by tiger (예 user:scott, passwd:tiger)

 

LIBTUX_CAT:466 ( TMS_ORA920 booting failed )

(1) 메시지 내용

TMS_ORA920.2196: LIBTUX_CAT:466: ERROR: tpopen TPERMERR xa_open returned XAER_INVAL

원인 : 1) ubb file의 OPENINFO에 oracle user/passwd 가 오류

해결방법

1) ubb file의 OPENINFO의 oracle user/passwd를 맞게 세트한다.

OPENINFO="Oracle_XA:Oracle_XA+Acc=P/user/passwd+SesTm=60+LogDir=log_path+DbgFl=15"

 

LIBTUX_CAT:466

메시지 내용 :

TMS_ORA920.2196: LIBTUX_CAT:466: ERROR: tpopen TPERMERR xa_recover returned XAER_RMERR

원    인 : xa table에 대한 권한이 없을 때

해결방법 : xa table에 대한 권한을 부여한다

grant all on v$xatrans$ to scott;

 

LIBTUX_CAT: 476,477

메시지내용 : 476: WARN: Server 1/6: client process 24969: lost message

477: WARN: SERVICE=ab_qf_ret_01 MSG_ID=1179490848 REASON=server died

원    인 : GROUP1의 서버 6 번이 죽었기 때문에 24969 client 프로세스가 보낸 메시지가 처리되지 못했음을 뜻한다. 서버 6이 죽는 원인은 서비스 ab_qf_ret_01 이다.

해결방법 : 서비스 ab_qf_ret_01 의 내용을 수정해야 한다.

 

LIBTUX_CAT:488

메시지내용 : 329: ERROR: Invalid data pointer given to tpreturn

원    인 : tpreturn의 세번째 argument에 잘못된 pointer을 넘김

해결방법 : STRING buffer type의 경우 null terminating 인 것으로 세번째 argument를 세트한다.

 

LIBTUX_CAT:518

메시지내용 : Service xxx failed to call tpreturn or tpforward

원    인 : tpreturn시에 포인터 오류 또는 tpreturn을 만나지 못함

해결방법 : 해당 서비스 루틴에서 tpreturn을 만나지 못하는 경우를 찾아 없앤다

 

LIBTUX_CAT: 522

메시지내용 : INFO: Default tpsvrdone() function used

원    인 : 오류 내용이 아님.

해결방법 : 서버를 shutdown 시에 시스템이 제공하는 default 서버 종료 루틴이 사용되었다는 메시지임

 

LIBTUX_CAT: 525

메시지내용 : INFO: Default tpsvrinit() function used

원    인 : 오류 메시지 아님

해결방법 : 서버를 올릴 때 시스템이 제공하는 default 서버 초기화 루틴이 사용되었다는 메시지. 즉, 정상 booting 되었음을 의미한다.

 

LIBTUX_CAT:541,551

메시지내용 : 541: WARN: Server GROUP2/110 terminated

             551: WARN: Cleaning up server GROUP2/110

원    인 : GROUP2의 server id 가 110인 프로그램에 오류가 존재

(1) 원    인 : 포인터 사용이 잘못됨

(2) 원    인 : 준비된 버퍼 크기가 부족하다

(3) 원    인 : 할당되지 않은 memory 에 copy

(4) 원    인 : 사용한 memory를 free 하지 않는다

해결방법 : (1) 포인터를 사용한 복사 등에서 잘못된 포인터를 수정한다.

(2) 할당된 버퍼크기보다 더 많은 데이터를 복사하고 있는지 확인한다.

(특히 strcpy 같은 함수를 사용할 경우 소스 데이터에 NULL 값이 있는지 확인한다)

(3) memory를 할당해 준다.

(4) memory를 free 해 준다.

*** 일반적인 검사순서

(1) compile 시에 warning 이 있는 위치를 확인한다.

(2) 메모리 혹은 스트링 복사시 각 메모리의 크기를 확인한다.

(3) 프로그램에 디버그 문장을 넣어서 죽는 위치를 확인하여 검사한다.

(4) COMPILE 시에 WARNING 이 있는 위치를 확인한다.

 

LIBTUX_CAT: 577

메시지내용 : ERROR: Unable to register because the slot is already owned by another process

원    인 : tmboot 나 tmshutdown 시에 다른 관리자가 이미 이를 수행중에 있기 때문에 발생함.

해결방법 : ps -ef | grep tmshutdown 또는 ps -ef | grep tmboot 를 이용하여 다른 관리자가 수행중인 프로세스를 찾고, 이를 kill 시키든지 아니면 그 프로세스 수행이 끝날 때까지 기다린다.

 

LIBTUX_CAT: 582

메시지내용 : ERROR: Unable to register, registery table full

원    인 : TUXEDO 시스템이 이 프로세스에 대한 registery table slot를 찾으려 했으나, 이미 테이블의 공간이 꽉 찬 상태임.

해결방법 : ubbconfig 파일의 MAXACCESSERS의 수를 늘려주고, tuxconfig를 다시 compile 한후 다시 booting을 시도한다.

 

LIBTUX_CAT:594

메시지내용 : 594: ERROR: Unable to locate PE entry in the bulletin board.

원    인 : 구성 파일의 machine section의 machine 이름과 현재의 machine이름이 다를 때, 즉 machine의 장애로 tuxedo engine이 다른 machine에서 운영될 때 native client에서 발생

해결방법 : native client의 환경 변수의 PMID에 구성 파일의 machine 이름을 세트한다.

예: export PMID=seoul1 (machine이름 : seoul1 )

 

LIBTUX_CAT: 666

메시지내용 : 666: ERROR: Message operation failed because the queue was removed

ERROR: msgrcv err ( LIBTUX_CAT:666: ERROR: Message operation failed because the queue was removed): errno=36, qid=0, buf=1637352, bytes=3996, type=0, flag=0

원    인 : messagequeue 가 지워졌기 때문에 queue로 메시지를 보낼 수 없다는 메시지로 IPC 자원을 강제로 clear 시켰을 때 떨어지는 메시지이다.

해결방법 : 조치할 내용 없음

 

LIBTUX_CAT : 743

메시지 내용 : No service TMS in group AUTH_XA_1

원    인 : AUTH_XA_1 group에 트랜잭션 요청을 하였으나 그 그룹 내에는 Transaction Manager Server 가 존재하지 않거나 뜨지 않은 상태임.

해결방법 : 해당 그룹의 TMS_ORA920을 선언해 주거나 서비스 호출시 TPNOTRAN 모드로 사용하거나 서버가 떠있지 않은 경우에는 서버를 띄워 준다.

 

LIBTUX_CAT:1122

메시지내용 : invalid driver designator

원    인 : login connect string contains an invalid driver designator

해결방법 : TWO_TASK=P: 지정 삭제

 

LIBTUX_CAT: 1122

메시지내용 : ERROR: No space in bulletin board

원    인 : Bulletin board 의 등록 table의 공간 부족으로 어플리케이션 시스템에 접속하려는 시도가 실패한다.

해결방법 : (1) 실패한 프로세스가 client 라면, 구성 파일의 *RESOURCES 섹션에서 MAXACCESSERS 를 늘려 주어야 한다.

(2) 실패한 프로세스가 서버 프로세스라면, 구성 파일의 *RESOURCES 섹션에서 MAXACCESSERS나 MAXSERVERS 또는 둘 다 늘려 주어야 한다.

(3) MAXACCESSERS는 특정 machine의 Bulletin Board에 동시에 접속할 수 있는 프로세스의 최대값을 의미하며 MAXSERVERS는 전체 시스템에서 구동시킬 수 있는 서버 프로세스의 최대값을 의미한다.

 

LIBTUX_CAT: 1199

메시지내용 : ERROR: Cannot re-attach: operating system error: errno=22

원    인 : 어플리케이션 시스템이 SYSTEM_ACCESS 값이 PROCTED 인 상태에서 client나 서버가 Bulletin board 에 재접속 하는 것이 실패. 이는 client나 server 가 Bulletin Board에 접속되어 있는 상태에서 비정상적으로 shutdown 되었음을 뜻한다.

해결방법 : errno를 조사하여 실패의 원인을 찾는다.

 

LIBTUX_CAT: 1233

메시지내용 : ERROR: Unable to shutdown, clients/servers still attached

원    인 : client 나 server 가 아직 Bulletin board에 접속되어 있기 때문에 BBL이 그 자신을 shutdown 시키지 못한다는 메시지. BBL은 그 자신을 shutdown 시키기 전에 먼저 Bulletin board를 제거해야 되기 때문이다.

해결방법 : (1) 먼저 BBL을 shutdown 시키기 전에 모든 application이 shutdown 되었는지를 확인하고, tmadmin의 pclt 명령어를 통해 모든 client가 접속을 끊었는지를 확인한 후에 BBL을 shutdown 시킨다.

(2) 만약 client가 아직 Bulletin board에 접속 상태라면, tmshutdown -c option을 사용할 수 있다.

        -c 옵션은 client 가 Bulletin board에 접속 상태라도 BBL을 shutdown 시킬 수 있도록 해 준다.

 

LIBTUX_CAT: 1234

메시지내용 : ERROR: Invalid data pointer given to tpreturn()

원    인 : 해당 프로그램내에 tpreturn 중에서 이미 free가 된 버퍼 혹은 잘못된 포인터로 tpreturn 함수를 호출하는 경우가 있음.

해결방법 : 해당 프로그램의 tpreturn에서 버퍼 포인터를 확인하여 수정.

 

LIBTUX_CAT:1254,340,248

메시지내용 : 1254: ERROR: shmget(creat) failure : errno=22, key=462179

340 : ERROR: Wrong configuration file

248 : ERROR : System init function failed, Uunixerr=: shmget: Invalid argument

원    인 : ipc parameter 중 SHMMIN 이 너무 큰 값(=32)으로 세팅되었음.

해결방법 : SHMMIN 을 1로 세트

 

LIBTUX_CAT:1276

메시지내용 : WARN: Forcing deletion of table entries for server GRP5518/351

원    인 : 서버가 죽었으며, BBL은 이를 clean up 하거나 restart 하는데 실패했음을 의미한다. 이 서버에 대한 서비스 , 서버의 entry는 Bulletin board로부터 지워진다.

해결방법 : 조치 방법 없음.

 

LIBTUX_CAT: 1282

메시지내용 : WARN: tpreturn message send blocked, will try file transfer

원    인 : 서버가 tpreturn()을 통하여 client에게 메시지를 보낼 때 message queue가 blocking 된 상태를 만났다는 메시지임.

해결방법 : 이 상황에서 TUXEDO는 temporary file을 이용하여 메시지를 return 하려고 시도하게 되며 이 때 performance는 떨어질 것이다. Message queue의 사이즈와 관련된 kernel parameter를 살펴보고 이를 조정한다.

 

LIBTUX_CAT: 1289

메시지내용 : ERROR: File transfer write failed, file=/var/tmp/aaaa006dm, errno=No space left on device

원    인 : /var/tmp/aaaa006dm 에 data를 write 하기 위한 unix kernel의 write() call이 실패. 이 temp 파일은 같은 machine내 두개의 TUXEDO system 프로세스간의 큰 메시지 이동이 있을 때 사용된다.

해결방법 : tmp 가 속한 파일시스템의 permission, space를 살펴서 permission 문제인 경우는 적절한 permission을 부여하고 space 문제의 경우는 space를 확보해 준다.

 

LIBTUX_CAT: 1309

메시지내용 : tpcommit failed to send message to TMS server

원    인 : application이 tpcommit를 호출하여 이 처리를 위해 transaction manager에게 요청을 보냈으나 해당되는 TMS(Transaction Manager Server)가 존재하지 않는다.

해결방법 : 그 전 혹은 후에 발생한 userlog 메시지를 잘 살피고, application 서비스내에 포함되어 있는 모든 resource Manager에 대하여 사용 가능한 transaction server 가 있는지를 확인한다.

 

LIBTUX_CAT: 1397

메시지내용 : WARN: tpreturn transaction processing failure

원    인 : tpreturn이 transaction processing error를 만나서 transaction이 abort 되었음을 의미한다. 서비스 루틴 자체가 시간이 너무 오래 걸려서 tpreturn()이 호출되기 전에 transaction이 timeout 된 것이다.

해결방법 : 이런 경우에는 tmadmin의 pt(printtrans) 명령을 이용하여 현재의 transaction 상태를 확인한 후에 abort나 commit 명령을 이용하여 이를 처리한다.

 

 

5. LIBWSC 관련

 

LIBWSC_CAT:1011,1049

메시지내용 : 1049: ERROR: Encoding of message data failed

1011: ERROR: tpcall() message failure

원 인 :    client에서의 view 파일과 server 에서의 view 파일이 다름.(server의 view 파일을 client로 copy 해서 발생)

해결방법 : client의 view 파일을 새로 생성.

 

 LIBWSC_CAT:1020,1027

메시지내용 : 1020: ERROR: Unable to obtain authentication level

1027: ERROR: Unable to connect to WSH

원 인 :   TUXEDO system/T 어플리케이션에 접속하려는 시도가 tpchkauth() 함수를 호출하는 호출하는 과정에서 실패하였다는 메시지. 이는 대개 WSNADDR이나 WSDEVICE 변수가 아예 설정되어 있지 않을 때 발생한다. 또 다른 경우는 네트워크가 다운되었거나, WSH가 다운되었을 때, 혹은 WSL이 떠 있지 않을 때이다.

해결방법 : WSNADDR을 구성 파일에 설정된 WSL의 listening 어드레스로 설정하여야 하며 WSDEVICE는 TLI를 사용할 때에만 설정하면 된다. 그리고 관리자는 WSL이 제대로 동작중인지를 살펴야 한다.

 

LIBWSC_CAT: 1021,1029

메시지내용 : 1021: ERROR: Encoding of message data failed

1029: ERROR: Sending of reply message to client

원 인 :      AP에서 Fsizeof 대신 Fused를 잘못 사용하여 발생

해결방법 :   Fused ---> Fsizeof 수정

 

LIBWSC_CAT: 1033

메시지내용 : ERROR: failure to get a message reply

원     인 : Workstation Handler로부터 메시지를 받으려는 시도가 실패했슴을 의미한다. 이 원인은 network의 down, WSH(Workstation Handler)의 부재 혹은 WSH의 다운 등이다.

해결방법 :  client를 down 시키고 TUXEDO 관리자는 client entry로부터 이 client의 정보를 삭제해야 한다.

 

LIBWSC_CAT: 1055

메시지내용 : ERROR: Unable to establish WSL connection

원      인 : WSL(Workstation Listener)에 접속되지 않는다.

(1) 접속을 하기 위한 address 가 틀렸거나, 혹은 WSL이 떠 있지 않은 경우

(2) network이나 machine이 다운되어 있는 경우

해결방법 :   환경 변수 WSNADDR에 설정된 어드레스가 구성 파일의 WSL 설정 부분에 있는 어드레스와 일치하는지를 확인하여 수정한다.

 

WSNAT_CAT :1042

메시지내용 : ERROR: tpcall call failed , tperrno = 6(TPENOENT)

원      인 : tuxedo service 떠있지 않거나 service가 속한 서버가 떠있다 오류에 의해 내려간 경우

해결  방법 : 서비스를 올려준다.

 

WSNAT_CAT  : 1198

메시지내용 : WARN: Forced shutdown of client; username sylee; client name pb sample

원      인 : client와 WSH의 연결이 비정상적으로 끊어졌을 때 나타나는 메시지이다.(즉, 클라이언트가 tpterm을 호출하지 않았을 때) 다음의 3가지로 나누어 생각해 볼 수 있다.

(1) 클라이언트가 연결된 상태에서 WSH를 shutdown 시켰을 때.

(2) client의 연결이 timeout 되었을 때, 이 timeout은 WSL에서 -T option을 주었을 때 설정되며, 단위는 초이다.

(3) WSH가 client에게 network 메시지를 보낼 수 없을 때(network 장애)

해결 방법 : 조치 내용 없음.

 

 

6. Oracle 관련

ORA-00022, 23 번 오류

원    인 : ORACLE OPS 사용시 oracle의 patch 적용 오류 또는 OS patch 오류.

해결방법 : 관련 patch가 정확히 이루어지도록 관리자에게 알린다.

 

ORA-00151 오류

메시지내용 : global transaction commit 오류 발생. 이 때의 xa trace file xa_NULLmmddyy.trc 내용에 다음의 내용 포함.

ORA-00151: invalid transaction ID

원    인 : TUXEDO 구성 파일의 OPENINFO의 SesTm 값이 작아 발생.

해결방법 : 구성 화일내의 OPENINFO에서 SesTm 값을 조정한다. 이 때 stderr 파일에 있는

           서비스들의 수행 시간을 고려하여 SesTm을 적당한 값으로 세트한다.

 

OR-00604 오류

메시지내용 : Recursive SQL level

원      인 : oracle의 init.ora 에 sessions 가 부족

해결  방법 : sessions 증가

 

ORA-00918 오류

메시지내용 : column ambiguously defined

원      인 : select 시에 table 지정을 하지 않음.( 2 개의 table에 동일한 column 이 존재)

해결  방법 : select 시에 대상 table을 지정.

 

OR-00994 오류

메시지내용 :

원      인 : array processing에서 server가 client로부터 수신된 건수 이상의 데이타 insert 시도시에 발생

해결  방법 : 지정된 occurrence 만큼 insert 하도록 수정

             occ = Foccur(......).

             EXEC SQL for :occ insert test(테이블 이름)

 

ORA-01401 오류

메시지내용 : inserted value too large for column.

원      인 : tuxedo가 사용하는 변수 사이즈가 DB table의 사이즈보다 작게 설정되어 있음

해결  방법 : 해당 변수의 사이즈를 table의 사이즈에 1을 더한 사이즈로 정한다.

 

ORA-01458 오류

메시지내용 : invalid length inside variable characters string

원    인 : varchar 변수의 length가 제대로 설정되지 않음.

해결방법 : 해당 프로그램 수정 필요

 

ORA-02048 오류

메시지내용 : attempt to begin distributed transaction without logging on

원      인 : client program must issue a distributed tr login.

해결  방법 : see 2049 error

 

OR-02049 오류

메시지내용: 2049 : timeout : distributed transaction waiting for lock.

1591 : lock held by in-doubt distributed transaction ID

원     인 : XA 루틴 중에서 xa_prepare 는 1 단계 commit를 수행하고 xa_commit는 2 단계 commit를 수행한다. 만일 MASTER에서 1단계 commit는 성공하고 2단계 commit은 실패하고 SLAVE에서는 1, 2 단계 commit이 모두 성공한 경우 MASTER에서는 transaction이 pending 상태로 되며, 이것에 의해 해당 transaction이 lock을 유지하고 있는 부분을 액세스하고자 하는 프로세스들은 2049 오류를 발생한다. 또한 서비스의 수행은 마치고 commit를 수행하는 단계에서 lock 해제를 기다리다 SesTm 에 의해 sesssion이 끊기면 1591 오류를 발생한다.

해결 방법 : (1) TMS_ORA920 을 3 - 5 개로 늘려준다.

            (2) ubbconfig 파일의 OPENINFO에서 SesTm=60 이상으로 설정

                (client에서는 tpbegin의 timeout + scanunit 보다는 큰 값으로 설정)

            (3) $ORACLE_HOME/dbs/initORA920.ora 파일에 정의되어 있는 process 수를 증가시킴.

 

ORA-02088 오류

메시지내용 : distributed database option not installed.

원    인 : Remote and distribited updates and transactions are a separate priced option in ORACLE V7

해결  방법 : ORACLE 분산 DB option 추가 설치

 

ORA-03113 오류

메시지내용 : end of file on communication channel.(OPS 사용시)

원      인 : /etc/group 화일의 DLM group에 tuxedo 사용자 id 가 미등록

해결  방법 : tuxedo 사용자 id를 DLM group에 등록

 

libclntsh.so 를 찾지 못함

메시지내용 : oracle의 shared library 인 libclntsh.so 를 찾지 못함

원      인 : Application Compile시 나타나는 에러로써 대부분은 환경 세트 오류이나 모든 환경 변수가 맞게 세트된 경우에도 발생하며 이 때는 환경 부분의 문제이나 정확한 원인을 알 수 없음

해결 방법 : libclnysh.so를 /usr/lib에 symbolic link 하고 /usr/lib가 LD_LIBRARY_PATH 또는 SHLIB_PATH 또는 LIBPATH 에 세트되도록 한다.

 

Oracle 관련 tuxedo service의 성능 저하

원    인 : oracle table 변경 작업 후 analyze 작업을 하지 않음.

해결방법 : oracle 관련 analyze 작업 수행