티베로 DB를 사용 하던 도중

JDBC-90611:ERRJD 해당 에러를 확인했다.

쿼리도 이상없고, 소스도 이상없는것 같아서 한참동안 헤메다가 원인을 발견했다.

ibatis를 사용하는 경우 동적으로 table name과 column name을 생성하여
쿼리를 실행해야 하는 경우가 발생한다.

예를 들면 다음과 같다.
<select id="fileInfo"  resultClass="java.lang.String" parameterClass="java.util.Map">
    SELECT $columnName$
      FROM $tableName$
    WHERE $pkName$ = #pkValue#
</select>

전혀 이상없는 구문이나 실행시 에러가 발생한다.
이상하게도 처음 실행시에는 에러가 발생하지 않으나,
두번째 부터 에러가 발생하기 시작한다.

WAS를 재기동하면 또 첫번째는 이상없으나, 두번째 부터 에러가 발생한다.

ibatis는 특정 id의 쿼리를 실행 한 후 해당 id의 쿼리를
캐쉬로 보관하고 있다가
동일한 id에 대한 요청시 캐쉬에 저장된 쿼리정보를 토대로 result값을 맵핑 시킨다고 한다.
(ibatis에서 제공하는 CacheModel과는 전혀무관한 얘기임)

이를 해결하기 위해선 remapResults="true" 속성을 추가해 주면 된다.
default remapResults="false" 이기때문에 항상 요청된 id와 동일한게
캐쉬에 저장되어 있다면 캐쉬의 내용으로 맵핑하려 할것이고
에러가 날것이다. 위 속성을 true로 지정하면
캐쉬의 내용을 무시하고 현재의 값을 가지고 맵핑시킴.

즉 아래와 같이 사용하면 된다.
<select id="fileInfo" remapResults="true"  resultClass="java.lang.String" parameterClass="java.util.Map">
    SELECT $columnName$
      FROM $tableName$
    WHERE $pkName$ = #pkValue#
</select>


출처: https://jace.tistory.com/57 [Jace's Blog]

리눅스 환경에서 실행

1. mysqldump명령어로 .sql파일을 만든다.

    #mysqldump -uroot -p [database명] > [파일이름].sql

    ex) #mysqldump -uroot -p tok > /경로/dumpTok.sql

   이렇게 하고 파일 리스트를 확인해보면 dumpTok.sql 파일이 생성 되어있다.

그리고 ftp나 여러 방법으로 dumpTok.sql파일을 새로운 서버(서버 이전 하고 싶은)에 옮긴다. 위치는 아무데나 상관없다.

*특정 테이블의 구조만 dump 하고 싶을 때 (-d 옵션 사용)

# mysqldump –d –u디비사용자명 –p패스워드 데이터베이스명 > 백업할파일명.sql

ex) #mysqldump -d -uroot -p tok table1 table2 table3 > /경로/dumpTok.sql

*특정 테이블만 dump 하고 싶을 때 (데이터 까지 같이 )

# mysqldump  –u디비사용자명 –p패스워드 데이터베이스명 > 백업할파일명.sql

ex) #mysqldump -uroot -p tok table1 table2 table3 > /경로/dumpTok.sql

2. 새로운 서버에 접속한다.

mysqladmin -uroot -p create tok  //database 를 생성한다. (같은 기능을 동작하기 위해 이름을 동일하게 했다) 

mysql -uroot -p tok  < dumpTok.sql //tok이란 database에 dumpTok.sql을 실행

이렇게 하면 database에 데이터가 들어간 것을 확인할 수 있다.

Clob 데이터는 다루기가 참 까다롭더라구요.

그래서 아예 SELECT 할때 이 타입을 VARCHAR2 타입으로 변경해서 SELECT를 진행했습니다.

SELECT DBMS_LOB.SUBSTR(컬럼명, 4000, 1)

FROM 테이블

물론 4000 글자가 넘어가면 잘리는 현상이 있습니다.

오라클에서 여러 개의 단어를 LIKE로 검색하기 위해서는 동적 쿼리를 사용하거나 LIKE를 OR로 묶어서 사용했다.  

Oracle 10g부터 정규식 함수가 추가 되었으며 그 중에서 REGEXP_LIKE 함수를 사용하여 다중 검색을 쉽게 할 수 있게 되었다.

검색할 단어를 파이프(|)로 연결하여 하나의 문자열로 만든 후 사용하면 된다.

SELECT *
   FROM TABLE
 WHERE REGEXP_LIKE(TEXT, 'A | B | C')

ORA-00054: resource busy and acquire with NOWAIT specified

위와 같은 에러메시지가 출력되면서 해당 DML이나 DDL 명령이 안될때가 있다.

증산은 DML문장이나 DDL문장 실행을 하게 되면 그냥 멈춰버리는 증상이다.

원인은 Commit이 수행되지 않았을 경우등의 문제로 발생하는 등 원인이 다양하다.

어쨋든 이 증상은 해당 테이블이 바쁘게 사용중일 때 나타나는데 일명 LOCK이 걸린것이다.

가장 확실한 방법은 DB를 재시작하는 것이다.

그러나 사실 필드에서는 말도 안되는 짓이다. 서비스중인 db를 잠깐이라도 내린다는것 자체가 미친짓이라 할 수 있다.

허나, test용으로 만든 서버라면 db재시작도 상관없다.

결국은 아래와 같이 Lock을 풀어주는게 가장 적당한 방법이다.

1. sqlplus 오라클 접속(시스템 계정으로 접속한다. 토드로 이용해도 무관)

#sqlplus / as sysdba

2.SQL> select a.sid, a.serial#

            from v$session a, v$lock b, dba_objects c
            where a.sid=b.sid and
            b.id1=c.object_id and
            b.type='TM' and c.object_name='TABLE이름';

위 명령어를 입력하면 SID와 SERIAL NUMBER가 출력된다.

LOCK이 걸린 테이블의 SID이다.

3. 세션을 죽인다.

SQL> alter system kill session 'SID, SERIAL';

여기까지는 시스템계정을 알고 있는 사용자에 한해서의 해결책이다.

일반 사용자는 어떻게 할것인가???

간단하게 commit 명령어로 해결될 가능성이 높다. 이 명령어가 수행되고 나면 restore작업은 불가능하다.

SQL>commit

SELECT A.TABLE_NAME FROM COLS A, TAB B WHERE A.COLUMN_NAME = '컬럼이름' GROUP BY TABLE_NAME

테이블 내의 컬럼이 뭐가 들어있는지, 속성은 무엇인지 알고 싶을 때 사용하는 쿼리

SELECT

    TABLE_NAME,

    COLUMN_NAME,

    DATA_TYPE,

    DATA_LENGTH,

    DATA_PRECISION,

    DATA_SCALE,

    NULLABLE,

    COLUMN_ID,

    DATA_DEFAULT,

    CHAR_LENGTH

FROM

    USER_TAB_COLUMNS

WHERE

    TABLE_NAME = 'SA_MEMBER'

UPDATE문을 짜다가

UPDATE TABLE1 SET A = (SELECT D FROM TABLE2 WHERE G='AAA'),

B=(SELECT E FROM TABLE2 WHERE G='AAA')

WHERE H='111'

이런식으로 작성하다가 이건 너무 비효율적인 방법이라서 찾아봤는데

아래와 같은 방법이 있었다....

UPDATE TABLE1

SET( A, B, C) = (SELECT D, E, F FROM TABLE2 WHERE G= 'AAA')

WHERE H = '111'

매우 간단하죠~?ㅋㅋ