인스턴스가 코드페이지를 가지는 것이 아닙니다.
인스턴스는 코드페이지와 무관하며, 설정하신 DB2CODEPAGE 파라메터는 클라이언트 입장에서 코드페이지를 지정한 것 뿐입니다.
기본적으로 DB2에서 호환가능한 코드페이지일 경우 코드페이지 컨버전을 자동으로 일어나지만 호환되지 못하는 코드페이지 지역상의
클라이언트나 서버측 코드페이지와 정확히 맞춰놓고 사용하고 싶을때 딱 꼬집어 지정해 놓는것일 뿐입니다.
하여, 현재 DB2 서버에 설정하신 DB2CODEPAGE는 서버에 직접 로그인해 들어간 콘솔이나 터미널 창에서 DB2 를 접속해서 들어가서
쿼리작업을 하게 될때 DB2를 접속한 터미널이 클라이언트 입장이 되어 지정한 코드페이지를 사용한것이란 말이지요.
즉, 다른 원격 시스템이나 클라이언트들은 각 자기 환경에서 코드페이지로 지정된 코드페이지를 사용할 뿐 서버에서 지정한 DB2CODEPAGE
와는 무관합니다.

하여, 중요한 것은 데이터베이스를 생성하실때 사용한 코드페이지 값(using codeset 절에 지정한 값) 에 따라 데이터베이스 코드페이지가 EUC KR이냐
UTF-8 이냐는 것이지 같은 인스턴스에 존재할수 없는 것이 아닙니다.

현재 데이터가 깨진것은 입력하실 때 어떤 입력방법을 이용하여 하셨는지 모르지만 유니코드 형태로 들어가야 할 데이터가 실제로는 EUC KR 형태로 들어있었던것이
옮겨진것으로 보입니다.
위에서 언급한 이유로 EUC KR 로 코드페이지가 되어 있는 데이터베이스에 DB2CODEPAGE를 1208을 한다고 해서 유니코드가 저장되는것이 아닙니다.
데이터베이스의 코드셋이 유니코드(UTF-8) 이어야 하고 클라이언트측에서 유니코드 환경으로 입력하셔야 합니다.


[ EUC KR codepage ]

Platform    Codeset      value
--------   ----------   -------
AIX          IBM-eucKR   970   
HP-UX     eucKR          970   
Linux       EUC-KR       970   
Solaris     5601             970    
Windows  1363             1363    

[ UNICODE codepage ]
DB2에서 유니코드 코드번호는 1200 과 1208 뿐이며, 1200 은 16비트 유니코드 형태(4바이트 유니코드 UTF...16...형태)로 저장하기 위한것이며, 
1208 은 UTF-8 에 근거해 8비트 호환성을 가지는 유니코드형태로서 기존 8비트 ASCII 데이터 호환성 문제를 피하려면 UTF-8 이 가장 유력한 코드번호이므로
통상 1208(UTF-8)을 설정합니다.(오라클의 UTF8과 다름)