'Daily/Prog'에 해당하는 글 109건

DBCP connection 유지

Daily/Prog 2021. 10. 6. 21:30
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 38,597,187 milliseconds ago.  The last packet sent successfully to the server was 38,597,188 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
Caused by: java.net.SocketException: Connection timed out (Write failed)

 

개발서버에서 작업 후 다음날 출근하여 동일한 웹페이지에서 쿼리를 보낼 때 발생하는 오류이다. 매일 아침 반복되고 있다.ㅋㅋ mysql connection 이 끊어진 것으로 보이는데... mysql 의 wait_timeout 옵션에 8시간으로 설정되어 있어, 이 시간이 지나고 쿼리를 보낼 때 발생하는 오류이다. autoReconnect=true 를 설정하라는 메시지가 보이지만 이미 설정된 상태이며, 같은 상황에서 이 옵션은 어쨌든 재접속에는 성공하겠지만 접속이 끊긴 상태에서의 첫번째 요청에는 에러를 발생시킬 것이다.

 

Caused by: java.sql.SQLException: Could not retrieve transation read-only status server
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 32,648,084 milliseconds ago.  The last packet sent successfully to the server was 20 milliseconds ago.
Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.

 

마찬가지 상황인데 이를 방지하기 위해서는 dbcp 설정을 추가/수정해야 한다.

 

 

- validationQuery : select 1
- testWhileIdle : true (커넥션 풀 안에 있는 유휴 상태의 커넥션을 대상으로 테스트 실행)
- timeBetweenEvictionRunsMillis : 7200000 (쓰레드가 동작하는 간격)
- testOnBorrow : true (커넥션  풀에서 커넥션을 가져올때 해당 커넥션의 유효성 검사 실행)

 

위는 2시간 마다 유휴 상태의 커넥션을 대상으로 'select 1' 쿼리를 실행하여 커넥션을 유지시키는 설정이며, naver d2 사이트에서 성능상 testOnBorrow 옵션과 testOnReturn 옵션은 false, testWhileIdle 옵션은 true 로 설정을 추천하고 있지만, 난 testOnBorrow 를 false 로 설정하면서 이 문제가 발생했다는...

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

ORACLE dump import

Daily/Prog 2021. 7. 22. 00:14

 

초보 오라클러가 오라클 데이터를 덤프받아 import 하며 간만에 크게 삽질한 과정을 적어본다. (난 도대체 언제까지 초보일껀가?) impdp 과정에서 오류나는 tablespace 열심히 만들고, 그 외에 유독 눈에 띄는 오류들이 있었다.

 

ora-12899: value too large for column actual x maximum n

 

아니 똑같은 스키마에 덤프 떠서 고대로 넣는데 먼 소린고... 

 

무시하다가 나중에 데이터를 확인했는데 같은 테이블에서도 어떤 컬럼은 한글이 깨지고 어떤 컬럼은 안깨지고... Mysql 에서도 테이블 별로 인코딩 설정은 가능하지만, 컬럼 별로 깨지고 안깨진다? 오라클 초보자로서는 당최 이해할 수가 없었는데 검색을 조금 해보니 알 것 같았다. KO16MSWIN949 의 2바이트짜리 한글들이 AL32UTF8 의 3바이트 한글로 넘어오면서 컬럼값이 넘친 것이니 인코딩 문제는 맞다. 아니 오라클 깔면 기본으로 UTF8 쓰게 되어 있는데 굳이 바꿔 가지고 이렇게들 피곤하게 할까잉...

 

오라클에서 인코딩 관련 설정 2개 / 언어 관련 설정 2개를 찾았다.

 

SELECT name, value$
FROM sys.props$
WHERE name IN ('NLS_LANGUAGE','NLS_TERRITORY','NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');

or

SELECT * 
FROM NLS_DATABASE_PARAMETERS 
WHERE PARAMETER IN ('NLS_LANGUAGE','NLS_TERRITORY','NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');

--NLS_LANGUAGE AMERICAN
--NLS_TERRITORY AMERICA
--NLS_CHARACTERSET AL32UTF8
--NLS_NCHAR_CHARACTERSET AL16UTF16

 

NLS_CHARACTERSET : char / varchar 데이터타입에서 사용하는 문자셋

NLS_VCHAR_CHARACTERSET  : nchar / nvarchar 데이터타입에서 사용하는 문자셋

 

 

역시 덤프 받아온 운영DB 와 NLS_CHARACTERSET 이 달랐고, varchar 의 한글만 문제가 발생한 것이다. KO16MSWIN949 로 인코딩 변경이 필요했다.

 

 

SQL> update props$ set value$='KO16MSWIN949' where name='NLS_CHARACTERSET';
SQL> commit;
SQL> shutdown immediate;
SQL> startup;

 

인터넷에서 대충 검색 해보고 뙇! 역시 천재라고 잠시 생각했지만, update 하면서 인코딩 값에 오타가 들어갔었는지 습관적으로 커밋은 했는데 startup 에 실패했다. 그 일순간의 오타로 오라클을 재설치까지 했다.ㅋㅋ nomount 하고 어쩌구 저쩌구 하면 가능하다고는 하는데, 난 모르겠고 빨리 재설치를 빨리 하는 것이 더 이득인 상황. 어짜피 이미 깨진 한글 다시 넣으려면 테이블들 다 확인해서 drop 을 하던 truncate 를 하던 해야 할 상황이었는데, 재설치가 빠르지... 라는 타협을 하고서는 ./deinstall ㅋㅋ 역시 뭔 프로그램이던 삭제는 참 빨라. $ORACLE_HOME 이랑 oradata 디렉토리도 비워주고 재설치 고고.

 

이번엔 미리 NLS_CHARACTERSET 인코딩 설정하고, profile 에 NLS_LANG 도 맞춰주고... impdp 뙇!

 

ORA-39006: internal error
ORA-39065: unexpected master process exception in DISPATCH
ORA-00600: internal error code, arguments: [kokle_lob2lob13:input mismatch], [1], [], [], [], [], [], []
ORA-39097: Data Pump job encountered unexpected error -600

 

아씨... 이럼 완전 나가린데...

 

한참 삽질 끝에 구글신이 도와주긴 했는데 이해는 안간다. NLS_CHARACTERSET 랑 DB internal 캐릭터셋이 따로 노는겨? 왜 둘다 바꿔줘야 하는겨? ㅡ.ㅡ 테스트 해보니 아래 방법이 NLS_CHARACTERSET 까지 확실하게 바뀌니, 아래 방법을 추천하는 걸로...

 

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter system enable restricted session;
SQL> alter system set job_queue_processes=0;
SQL> alter database open;
SQL> alter database character set internal_use KO16MSWIN949;
SQL> shutdown immediate;
SQL> startup;

 

alter database character set internal_use <- 요기가 포인트!

 

아무튼 긴~ 삽질끝에 덤프질 해결~


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Locale not recognized

Daily/Prog 2021. 6. 29. 00:38

 

Mac 에서 SQL Development 실행시 커넥션 테스트하면서 발생한 에러.

Status : Failure - Test filed : Locale not recognized

 

Locale 을 지정해주자...

 

$ vi /Users/xxx/Downloads/SQLDeveloper.app/Contents/Resources/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf
...
AddVMOption -Duser.language=ko
AddVMOption -Duser.country=KR

 

와 씨 드럽게 길다. 설정 같은데서 locale 선택하는 항목 하나 만들어 놓으면 될 것을 이렇게 거지같이 만들어 놨네...


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

SQL Development for Mac

Daily/Prog 2021. 6. 29. 00:27

 

Mac 에서 SQL Development 를 설치하는 방법은 간단하다. Oracle 사이트에서 SQL Development for Mac with JDK 8 을 다운받아 설치하면 끝이다. 하지만 나는 jdk1.8.0_65 가 깔려있었으므로 JDK 를 제외한 파일을 다운받았다. 다운받은 SQLDeveloper.app 파일을 실행했는데 jdk 버전이 낮다며 상위 버전을 요구했다. 최신버전인 jdk1.8.0_291 을 설치했다. 다시 SQLDeveloper.app 파일을 실행했는데 실행 즉시 셧다운 되는 현상이 나타났다. 아오...

java 버전도 jdk1.8.0_291 로 바뀐 것을 확인했는데, 뭔가 꼬인듯 했다. 장시간의 검색 끝에 JavaAppletPlugin 이란 것이 환경변수 설정을 방해한다는 것을 알게 됐고, 뿌리를 뽑아버렸다.

$ sudo rm -rf /Library/Internet Plug-Ins/JavaAppletPlugin.plugin

안타깝게도 빡쳐있던 나는 그 안에 내용물을 확인하지 않았지만 아마도 JRE 구버전이 설치를 방해하고 있었던 것이 아닌가 하는 어설픈 추측을 해본다. 참고로 저 명령어는 Mac 에서 JRE 나 JDK 삭제시 가장먼저 날리는 명령어이다.


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Tomcat 은 훌륭한 WAS 이다. 그대로 갖다 쓰면 되는 것을 이짓저짓 해가면서 에러를 발생시킨다. 오늘도 어김없이 뻘짓을 하다가 에러를 발생시킨다. Tomcat7 과 Tomcat8 을 동시에 올리는 과정에서 에러가 발생했다. 각각 그대로 썼다면 문제가 없었겠지만 멀티 인스턴스를 생성하는 과정에서 Tomcat7 기반에다가 Tomcat8 설정을 그대로 가져왔더니 에러가 발생했다. 왜 이런 짓을 했는지는 비밀이다.ㅋㅋ

 

28-Jun-2021 14:01:19.636 경고 [main] org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with directory [/app/tomcat7-jdk1.6/bin/"/app/instances/instance6/lib"], exists: [false], isDirectory: [false], canRead: [false]
28-Jun-2021 14:01:19.637 경고 [main] org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with directory [/app/tomcat7-jdk1.6/bin/"/app/instances/instance6/lib/*.jar"], exists: [false], isDirectory: [false], canRead: [false]
28-Jun-2021 14:01:19.637 경고 [main] org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with directory [/app/tomcat7-jdk1.6/bin/"/app/tomcat7-jdk1.6/lib"], exists: [false], isDirectory: [false], canRead: [false]
28-Jun-2021 14:01:19.638 경고 [main] org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with directory [/app/tomcat7-jdk1.6/bin/"/app/tomcat7-jdk1.6/lib/*.jar"], exists: [false], isDirectory: [false], canRead: [false]

 

음... 한글 로그가 참 눈에 거슬린다. 결론부터 얘기하자면 설정에 따옴표(") 가 붙은게 문제이다. tomcat8 에는 로더 간에 따옴표(")로 구분을 하였고, tomcat7 에는 따옴표가 없는데... 그 때문이다. 

 

(Tomcat8, conf/catalina.properties)
common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar"

(Tomcat7, conf/catalina.properties)
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar

 

필요에 맞게 따옴표(") 를 넣거나 빼면 된다. 

 

기본 그대로 잘 쓰면 에러 안난다.ㅋ


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret