목차

일반
IBM Cloudscape와 Apache Derby의 차이점은 무엇인가?
IBM Cloudscape는 무료인가?
임베디드(embedded)란 무엇인가?
임베디드 Derby가 멀티 유저 데이터베이스인가?
읽기 전용 연결 상태의 더블 부팅이 어떻게 파손을 유발하는가?
베이스 엔진 jar에 클라이언트/서버 지원이 없는 이유는?
Derby가 SQLJ를 지원하는가?
J2EE 애플리케이션 레벨에 Derby JDBC Driver가 전개되어서는 안되는 이유는?
설치 및 설정
Derby 환경을 설치하는 방법은?
전개 시 기본 컴포넌트는 무엇이 있는가?
임베디드 Server 아키텍처는 무엇인가?
인증과 권한을 만들 때 필요한 단계는?
Network Server를 설정하여 자바 보안 매니저 하에서 실행하는 방법은?
캐시 히트를 향상하고 I/O를 줄이기 위해 Derby를 튜닝 하는 방법은?
일반 사용법
데이터베이스와 스키마의 다른 점은 무엇인가?
특정 값을 칼럼에 삽입한 후에, Derby 아이디 칼럼을 위해 만들어진 값에서 중복 키 오류(ERROR 23505)를 피하려면 어떻게 해야 하는가?
한 개 이상의 데이터베이스에 하나의 애플리케이션을 연결하는 방법은?
데이터베이스에 테이블 이름들을 나열하는 방법은?
Derby 데이터베이스에 자바 함수를 만드는 방법은?
데이터 테이블에 대한 파일 이름을 찾는 방법은?
문제 해결
Derby용 개발 환경을 설정하는 방법은?
Derby를 실행할 때 OutOfMemory 예외를 피하는 방법은?
내 테이블과 인덱스의 무결성을 입증하는 방법은?
릴리즈
IBM Cloudscape, Version 10.1의 새로운 기능은 무엇인가?
10.1 버전에 새로운 클라이언트 드라이버 라이브러리가 있는 이유는?
IBM Cloudscape, Version 10.0은 어떤가?
참고자료
링크

위로

일반 질문

Q: IBM Cloudscape와 Apache Derby의 차이점은 무엇인가?

A: Apache Derby와 IBM Cloudscape는 핵심적인 기능에서는 차이가 없다. Version 10으로 시작하는 IBM Cloudscape는 Apache Derby Project(참고자료)의 일부로서 개발된 데이터베이스의 상용 구현이다. 2004년 8월, IBM은 IBM Cloudscape 제품의 소스 코드를 Apache Software Foundation (ASF)에 기여했다. 이 소프트웨어는 Derby로 이름이 바뀌었다. IBM은 IBM Cloudscape, Version 10을 만들었고 ASF 코드라인에서 직접 구현했다. IBM은 데이터베이스 엔진, 툴, 네트워크 서버 코드를 변경하지 않고, IBM Cloudscape로 재 패키지 하여 배포하고 있다.

핵심 기능을 제외하고는, IBM Cloudscape는 패키징과 IBM에서 제공하는 가치가 부여된 모듈과 툴 부분이 다르다. 핵심 제품은 갖기 때문에, 이러한 추가 모듈과 툴들은 Apache Derby나 IBM Cloudscape에서 사용될 수 있다. 두 제품 모두 핵심 레벨에서는 분간이 어렵다. 다음 리스트는 Derby와 IBM Cloudscape에서 사용할 수 있는 패키징, 모듈, 툴들이다.

• IBM Cloudscape는 확장 테스트를 수행하여 다운로드용 제품 릴리스 전에 코드라인의 안정성을 보장하고 있으며, 다음 사항들이 포함되어 있다:
  • 인스톨러 패키지에 묶인 메이저 릴리즈는 설정이 단순하다.
  • 각 인스톨러 패키지 내에서 Windows와 리눅스용으로 JRE의 IBM 구현
  • Network Server로 연결할 때 사용되는 DB2 JDBC 클라이언트 드라이버: IBM DB2 JDBC Universal Driver. [주: 오픈 소스 Derby Network Client V10.1은 이 라이브러리를 대신 사용된다.] 이 JAR 파일들에는 모든 IBM Cloudscape 인스톨러가 포함되어 있으며, ASF Derby 배포판에 개별 다운로드로서 사용될 수 있다. (참고자료 .)
  • PDF 포맷의 문서
• Derby용 ODBC 드라이버, IBM DB2 Runtime Client (개별 다운로드 가능). (참고자료 .)
• 데이터베이스 브라우징 툴, IBM DB2 plug-ins for Eclipse(다운로드 가능). .) [ 업데이트: 10.1 버전 이후, 더 작은, 향상 버전이 곧 릴리스 될 것이다.]

IBM Cloudscape 다운로드 페이지에서 모듈을 무료로 다운로드 할 수 있다. (참고자료 .)

IBM은 Cloudscape 사용자들에 서비스도 제공한다. IBM Cloudscape용 유료 Support 라이센스(참고자료)는 개인과 기업에 확실한 해결책을 제시한다. 이 오퍼링은 IBM 지원 부서로 음성 및 전자 액세스를 제공한다. 서비스 라이센스는 Derby의 IBM Cloudscape 배포판으로 제한되며, 머신 단위로 요금이 부과된다. 정식 지원 서비스를 필요로 하지 않는 개인과 기업의 경우에도, IBM은 developerWorks Cloudscape 웹 사이트와 IBM Cloudscape 커뮤니티 포럼에서 문서를 통해 무료 지원을 제공한다. (참고자료 .)

Q: IBM Cloudscape는 무료인가?

A: 그렇다. IBM Cloudscape는 무료로 다운로드 할 수 있다. 참고자료 섹션의 "Download free modules" 링크를 이용하라. 이 외에도, IBM Cloudscape가 무료로 재배포 될 수 있도록 허용한 라이센스도 있다.

Q: 임베디드(embedded)란 무엇인가?

A: Merriam-Webster OnLine Dictionary (http://m-w.com)의 정의 참조:

em·bed·ded; em·bed·ding - 타동사
1 a : 가까이 둘러싸이거나 매트릭스에 있는 것 같은 <fossils embedded in stone > b : 어떤 것의 중요한 부분이 되는 <the prejudices embedded in our language> c : (현미경 표본) 해체를 위해 준비된 지탱하는 물체에 박히거나 둘러싸인 것
2 : 가까이 두른 <a sweet pulp embeds the plum seed> 자동사 : 박히다.

"Embedded Derby"는 개별 데이터베이스 서버가 아니라는 것을 의미한다. Derby는 자바 애플리케이션에 설치된다. (한 개의 JAR 파일과 데이터베이스 파일들이 있다.) 같은 JVM에서 애플리케이션으로서 실행되며, 애플리케이션에 의해 부팅 및 중지된다. 엔드 유저는 이 안에 데이터베이스 시스템이 있다는 것을 알 필요가 없다. 관계형 데이터베이스 시스템의 모든 기능들을 갖춘 전개하기 쉬운 애플리케이션일 뿐이다. 애플리케이션 디자인 관점에서 볼 때, Derby는 DBMS 처럼 'Plug N Play' 된다.

Q: 임베디드 Derby가 멀티 유저 데이터베이스인가?

A: 그렇다. Derby는 멀티 유저 액세스를 지원한다. 어떤 전개 옵션이 사용되는지는 상관 없다. “멀티 유저(Multiuser)”는 엔진이 여러 개의 고립된 트랜잭션들을 필요할 때 마다 관리한다는 것을 의미한다. Derby 매뉴얼은 하나의 사용자 애플리케이션에서 Derby 사용법을 설명하고 있다. Derby는 이 아키텍처에서는 잘 실행되지만, 싱글 유저나 싱글 커넥션으로만 제한되지 않는다. Derby는 완전히 삽입된 전개에도 여러 커넥션을 지원한다. 각 커넥션은 개별 트랜잭션을 나타낸다. 하나의 애플리케이션은 여러 커넥션을 만들 수 있고, 따라서 여러 개의 독립적인 트랜잭션을 실행할 수 있다. 각 커넥션은 네 가지 레벨의 트랜잭션 고립화 중 하나를 지정하여 필요한 동시성 레벨을 제공한다. 트랜잭션 고립화 레벨, 동시성, 잠금 유형에 대한 자세한 설명은 Derby Developers Guide를 참조하라.

Derby JAR 파일에는 어떤 네트워킹 코드도 없다. 다시 말해서, Derby가 싱글 유저가 아니라는 의미이다. 비록 이러한 오해는 일반적인 것이지만. 네트워크 메시지는 Derby 엔진을 실행하는(프로세스간 통신) JVM 밖에서의 통신에 필요하다. 두 개의 독립 프로세스들 간 통신을 "Client-Server" 라고 한다. Client-Server의 기능의 필요에 맞추기 위해, Derby는 Network Server를 제공한다. (개별 JAR 파일로). Derby는 Network Server로 쉽게 삽입되어 필요할 때 마다 Client-Server 연결을 제공한다. Derby는 또한 다른 많은 서버 프로그램들(WebSphere, Apache Tomcat)에 쉽게 삽입되었기 때문에, 선택은 여러분에게 달려있다.

주의: 애플리케이션에 의한 연결 외에, 데이터베이스로 인터랙티브 연결이 필요하다면, 서버 환경(임베디드 서버아키텍처가 가장 유연하다.)을 사용하는 것이 좋다. 많은 경우, 데이터베이스 오염은 테스팅 시, 프로그래머가 개별 쿼리 툴을 사용하여 테스트 진행 상황을 모니터링 할 때 발생한다. 쿼리 툴은 자신의 JVM에서 실행되고, 연결이 허용되면, 데이터베이스를 ‘더블 부팅’(‘듀얼 부팅’)하여 데이터베이스를 오염시킨다. DB2 Help 사이트의 더블-부팅 섹션을 참조하라.

Q: 읽기 전용 연결로 Derby를 더블 부팅하면 오염을 초래하는가?

A: Derby 데이터베이스로의 첫 번째 연결은 데이터베이스를 “부팅”한다. 부팅이란 의미는 모든 메모리 구조와 프로세스들이 초기화 되고(캐시, 매니저, 리스트 등), 데이터 사전이 읽히고, 트랜잭션 로그에서 커미트 되지 않은 트랜잭션이 롤백 된다는 것을 의미한다. 더블 부팅(듀얼 부팅) 시나리오에서, 커미트 되지 않은 트랜잭션이 다른 JVM 프로세스에서 활성화 되면, 이 롤백은 오염을 일으킨다. 따라서 연결 유형은 문제가 되지 않는다. 데이터 무결성을 유지하기 위해서 트랜잭션 로그의 불완전한 트랜잭션을 복구할 것이기 때문에 데이터베이스를 부팅하는 행위는 문제가 되지 않는다.

가능하다면, Derby는 더블 부팅을 탐지 및 방지하지만, 최근까지, 모든 환경에서 이것이 불가능했다. 1.4 버전 또는 그 이상 버전의 JVM을 사용하면, Derby로 유닉스, 리눅스, 기타 운영 체계에서의 더블 부팅을 막을 수 있다. 이전 버전의 JVM이 사용되어야만 하는 시스템의 경우, derby.database.forceDatabaseLock=true로 속성을 설정하면 듀얼 부팅을 최소화 할 수 있다. forceDatabaseLock 설정의 한 가지 부작용은 데이터베이스 잠금 파일(db.lck)이 언제나 데이터베이스가 부팅된다는 것을 막는다는 점이다. 데이터베이스가 올바르게 셧다운 되지 않으면(충돌 또는 중지(abort)), ‘고아’ 데이터베이스 잠금 파일이 남겨지게 된다. forceDatabaseLock이 설정되면, 이 고아 파일은 직접 제거해야 한다. 일반적으로, Derby는 고아 데이터베이스 잠금 파일들을 탐지하여 올바르게 핸들하지만, forceDatabaseLock은 다른 프로세스가 파일에 대해 잠금 활성화가 되었는데도 부팅을 방지한다. 데이터베이스 잠금 파일을 직접 제거하기 전에, 데이터베이스 머신에 어떤 JVM도 실행되지 않도록 해야 한다.

Q: 베이스 엔진 jar에 클라이언트/서버 지원이 없는 이유는?

A: 많은 애플리케이션들은 하나의 시스템에서, 하나의 프로세스로 완벽하게 실행되기 때문에, Client-Server 기능이 필요치 않다. 예를 들어, Web 폼에 입력된 서블릿 소팅(sorting) 데이터나 PC에서 실행되는 주소록 애플리케이션은 다른 프로세스들과 통신할 필요가 없다. Client-Server 코드는 애플리케이션의 풋프린트를 늘릴 뿐 어떤 효용도 없다. 이 같은 애플리케이션의 경우, Derby는 불필요한 네트워킹 코드 없이, 관계형 데이터베이스의 모든 장점을 제공한다. Client-Server 기능은 인스턴스에 점증적으로 추가될 수 있는데, Network Server나 다른 서버 아키텍처를 실행할 때 필요하다.

Q: Derby가 SQLJ를 지원하는가?

A: 아니다. Derby를 위해 특별히 구현된 SQLJ 구현은 없다. 몇몇 SQLJ 트랜슬레이터가 Derby와 함께 사용되어도 실패하지 않는 코드를 만들지만, 이는 테스트 되지 않았고, 코드의 퍼포먼스도 형편 없다. SQLJ 표준은 ‘벤더 커스터마이징’을 허용하여 가능한 최상의 결과를 이끌어낸다. 대부분의 SQLJ 구현은 주요 데이터베이스 벤더(Oracle, Sybase, IBM)들이 만들고, 데이터베이스에 맞춘 커스터마이징이 포함된다. 일반적으로, SQLJ에 관심이 있는 사람이라면, 단순한 JDBC 트랜슬레이터 그 이상을 원한다. 결과 코드가 빠르게 되거나, 직접 만든 프로그램 보다 빠르기를 기대하게 된다.

Q: J2EE 애플리케이션 레벨에 Derby JDBC 드라이버가 전개되어서는 안되는 이유는?

A: 대부분의 JDBC 드라이버를 구성하고 있는 통신 클래스뿐만 아니라, Derby 드라이버에는 DBMS 엔진 클래스가 포함되어 있기 때문이다. 이 드라이버가 처음 로딩되면, 엔진 부트와 내부 구조는 데이터베이스 액티비티를 수행하는 다른 JVM 쓰레드에 의해 액세스 될 수 있어야 한다. Derby 드라이버가 전개된 애플리케이션에 의해 처음 로딩되면, 이 같은 액세스는 불가능 하다. 애플리케이션 서버가 전개된 모듈(애플리케이션, JSP, 서블릿, EJB)을 고립시키는 제한된 클래스로더의 계층을 설정하여 이들이 서로서로 “스테핑”하는 것을 막는다. 올바르게 작동시키려면, 엔진 클래스는 볼 수 있는 JVM이어야 한다.(서버의 클래스로더 계층의 애플리케이션 레벨 위). 이로서 Derby 내부 쓰레드와 데이터베이스 요청을 하는 쓰레드는 요청된 기능을 수행하는데 필요한 클래스와 객체들로 액세스 할 수 있다. Derby는 삽입되었기 때문에, 이것을 로딩한 루틴의 권한을 상속받는다. Derby가 제한된 환경에서 부팅되면, 결과는 예측할 수 없다.

위로

설치와 설정

Q: IBM Cloudscape 환경을 설치하는 방법은?

A: 설치는 단순하고 자바 인스톨러를 사용하여 플랫폼과는 독립적으로 수행된다. (설치를 시작하는 명령행 신택스와 파일 경로 목적지는 플랫폼에 의존한다.) 지금 이것은 자바 인스톨러를 사용하여 설치를 하는 경우를 설명하는 것이다. 플랫폼 별 인스톨러는 Windows와 리눅스 환경에서 사용할 수 있다. install.html 파일에서 플랫폼 스팩 인스톨러를 사용하는 방법을 참조하기 바란다.

설치에는 기능을 수행하는 JVM과, 파일시스템에 알맞은 디스크 공간이 있어야 한다. JAR 파일에 4Mb, IBM Cloudscape 설치(javadoc와 샘플 포함)에 24Mb, 또는 (Windows 전용) IBM Cloudscape 설치에 64Mb, IBM JRE. 여기에는 설치 JAR 파일의 크기는 포함되지 않는다.

OS 명령행 프롬프트에서, IBM Cloudscape 설치 JAR 파일을 포함하고 있는 디렉토리로 간다. 다음 명령어를 입력하여 인스톨러를 호출한다.

<path-to-java-binary>\java -cp . -jar
<cloudscape-installation-jarfile>
         

여기에서:

• <path-to-java-binary>는 java.exe 파일에 대한 전체 경로이다. (환경 변수 JAVA_HOME으로 표시된다. )
• <cloudscape-installation-jarfile>은 설치 JAR 파일이다.

프롬프트:

• Initial screen (1): 정확한 제품이 설치되었는지 확인한다: Next를 클릭한다.
• Screen 2: "Yes, I would like to read the release notes now." 체크 박스에서 체크를 해제한다. Next를 클릭한다.
• Screen 3: 라이센싱 조건을 읽는다. 수락한다면, I accept the terms of the license agreement를 선택한다. Next를 클릭한다.
• Screen 4: 설치에 필요한 전체 디렉토리 경로를 확인 및 입력한다. Next를 클릭한다.
• Screen 5: 설치 선택을 확인하고 필요한 디스크 공간을 확인한다. Next를 클릭한다.
• Screen 6: Next를 클릭한다. Finish를 클릭한다.

설정/셋업

Q: Derby 전개의 기본 컴포넌트들은 무엇인가?

A: 애플리케이션 전개 시 핵심 Derby 컴포넌트들은, 1) JAR 파일, 2) 데이터베이스 파일, 3) 에러 로그이다. 이들은 전개 시 언제나 존재하며, 데이터베이스 레벨 작동 또는 디버깅이 발생하기 전에 배치되어야 한다.

Derby 전개를 논할 때, System Home의 개념도 중요하다. Derby System Home은 모든 파일들, 데이터베이스, Derby 로그들이 만들어지는 기본적인 장소이다. derby.system.home 속성을 설정하여 이 장소를 지정하지 않으면, 데이터베이스 엔진을 실행하는 JVM 프로세스의 현재 실행 디렉토리가 기본 장소가 된다. 실행 환경에 전개 시 System Home을 지정하는데 신중해야 하며, 그 위치도 문서로 남겨놓아야 한다. 첫 번째 데이터베이스로 연결하기 전에, derby.system.home을 설정한다. (“Derby 엔진 시작하기”)

에러 로그 파일의 디폴트 이름은 derby.log이지만, 이 이름은 설정 가능하고 애플리케이션 프로그래머가 변경할 수 있다. 기본적으로, 에러 로그는 derby.system.home에 만들어지고, 기본 위치 지정을 신중히 해야 한다. 에러 로그는 데이터베이스 레벨의 검사/디버깅 액티비티를 수행하는데 필요하다. Derby 전개 시 작동할 수 있도록 위치와 이름이 알려져야 한다. 로그에는 Derby 엔진에 의해 부팅된 모든 데이터베이스의 리스트들과 심각한 에러(덜 심각한 메시지와 경고를 포착하기 위해 derby.stream.error.logSeverityLevel을 설정하는 방법은 Tuning Guide, "Working with Derby Properties”를 참조하라) 등이 포함된다.

데이터베이스 파일(c2a10.dat)과 트랜잭션 로그 파일(log2.dat)은 메인 데이터베이스 디렉토리의 하위 디렉토리에 배치된다. 메인 디렉토리는 데이터베이스와 같은 이름을 사용한다. (toursDB). 데이터베이스 디렉토리로 가는 경로는 데이터베이스를 부팅하는데 필요하다. 메인 데이터베이스 디렉토리에는 최소한 두 개의 하위 디렉토리가 있다:

• "seg0" 에는 데이터 파일이 포함되어 있다.
• "log" 에는 트랜잭션 로그 파일이 포함되어 있다.

이러한 디렉토리에 있는 어떤 파일에도 직접 액세스 해서는 안된다.

derby.jar 파일에는 Derby 엔진을 실행하는 코드가 포함된다. 이 파일은 클래스 경로에 있으면서 임베디드 드라이버를 로딩하고 Derby 데이터베이스를 부팅해야 한다. Derby 개발 환경에는 Derby 전개에 포함된 기타 JAR 파일 옵션들이 포함된다:

• derbytools.jar - ij와 dblook 툴
  • ij - Derby 인터랙티브 JDBC 스크립팅 툴과 SQL 명령행 인터페이스
  • dblook - 데이터베이스에 있는 객체용 Data Definition Language (DDL)을 보거나 덤핑하는 Derby 유틸리티
• derbynet.jar - The Derby Network server
• derbyclient.jar - Derby Network Client. 이 클라이언트 라이브러리는 10.1 버전과 함께 사용할 수 있으며, 선호하는 클라이언트 라이브러리이다. Network Server Version 10.0과도 사용된다.
• db2jcc.jar와 db2jcc_license_c.jar - Network Server와의 클라이언트 통신을 지원하는 DB2 JDBC Universal Driver. [주: derbyclient.jar는 선호하는 클라이언트 라이브러리로서 Network Server에서 사용된다.]

Q: 임베디드 Server 아키텍처란 무엇인가?

A: 간단히 말해서, 임베디드 Server 아키텍처는 Derby와 통신할 수 있는 Server 프로그램이 Derby 엔진과 같은 JVM에서 실행될 때 만들어진다. 이 아키텍처에서는, JVM 내에서 실행되는 어떤 쓰레드도 임베디드 드라이버(org.apache.derby.jdbc.EmbeddedDriver)를 사용하여 Derby 데이터베이스에 액세스 할 수 있고, 개별 JVM에서 실행하는 쓰레드는 알맞은 클라이언트 드라이버를 사용하여 같은 데이터베이스에 동시에 액세스 할 수 있다. Derby 엔진(임베디드)와 직접 인터랙팅 하면서 내부 쓰레드가 효과를 보는 반면, 외부 쓰레드는 Server 매개체(클라이언트/서버)를 통해서 Derby와 통신한다.

Derby Network Server를 사용할 때, 임베디드 서버 아키텍처는 derby.drda.startNetworkServer 속성을 true로 설정하면 쉽게 만들어 질 수 있다. 이 속성은 엔진이 부팅되면, Derby가 Network Server를 자동으로 시작하도록 한다. 자바 명령행이나 derby.properties 파일에 이 속성을 설정하는 것 만으로도, Derby 임베디드 드라이버를 로딩하는 어떤 프로그램도 Network Server를 삽입한 채로 실행될 수 있다. 이는 임베디드 애플리케이션을 테스트 또는 디버그 할 때 특히 유용하다. 애플리케이션이 실행 중일 때 쿼리를 사용하여 데이터베이스를 모니터링 할 수 있는 기능을 제공하기 때문이다. SimpleNetworkServerSample.java 프로그램(Derby 배포판에서 제공됨)은 간단한 임베디드 서버 환경이다.

임베디드 서버 환경의 가장 일반적인 예는 Derby가 Tomcat이나 WebSphere 같은 애플리케이션 서버와 함께 사용될 때이다. 이 서버들이 시작 시 Derby 엔진을 로딩하도록 설정하면 임베디드 서버 환경이 만들어진다. 데이터베이스 엔진은 애플리케이션 서버와 같은 JVM에 존재하기 때문에, JSP, EJB, Servlet 같이 서버에서 실행되는 모든 애플리케이션들은 데이터베이스 액세스(글로벌 또는 서버 측 임베디드 데이터소스를 통해서)에 임베디드 드라이버를 사용할 수 있고 클라이언트/서버 통신의 오버헤드를 피할 수 있다. Derby와 애플리케이션 서버를 함께 사용하는 것에 대한 자세한 내용은 "Use Derby in a J2EE Server environment"를 참조하라. (참고자료)

Q: 사용자 인증과 권한을 만들 때 필요한 절차는?

A: Derby는, 보안이 점점 더 많이 필요해지고 다른 시스템들(LDAP)이 사용되지 않는 환경에서 사용될 수 있는 빌트인 사용자 인증(사용자 이름과 패스워드)와 사용자 권한(데이터 액세스 레벨) 시스템을 갖고 있다. 디폴트 설정에서는, Derby 인증과 권한이 사용되지 않는다. 다음 예제는 빌트인 프로바이더에 의해 인증을 활성화 하고, 두 개의 권한(액세스) 레벨을 할당하는 방법이다. 속성들은 유효 사용자 이름과 패스워드가 없으면 액세스를 허용하지 않도록 설정되고, 프로그래밍 방식으로 설정된 시스템 레벨 속성들에 의해 이러한 속성들이 오버라이드 되지 않도록 한다.
빌트-인 프로바이더에 의한 인증 활성화

					
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.connection.requireAuthentication', 'true') 

CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.authentication.provider', 'BUILTIN') 
          

					
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.Spot', 's06oh1r1')
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.Rover', 'j2um3u5u')
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.Dick', 'bt84ayNn9') 
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.Jane', 'aal379y0w') 
          

					
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.fullAccessUsers','Spot,Rover') 
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.readAccessUsers','Dick,Jane') 
          

					
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.connection.requireAuthentication', 'true') 
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.defaultAccessMode', 'noAccess')
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.propertiesOnly', 'true')
          

					
java org.apache.derby.tools.ij
ij version 10.1
ij> connect 'jdbc:derby:authdb';
ERROR 08004: Connection refused : Invalid authentication.
ij> connect 'jdbc:derby:authdb;user=Rover';
ERROR 08004: Connection refused : Invalid authentication.
ij> connect 'jdbc:derby:authdb;user=Spot;password=s06oh1r1';
ij>
          

					
ij> values SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY
      ('derby.database.fullAccessUsers');
1
------------------------------------------------------
Spot,Rover
ij> values SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY
       ('derby.database.readAccessUsers');
1
-------------------------------------------------------
Dick,Jane
          

인증 시 고려 사항

• derby.connection.requireAuthentication을 설정하기 전에 적어도 한 개의 완전한(Full) 액세스 사용자 계정을 만들어라. 그렇지 않으면 데이터베이스에 있는 데이터를 조작할 수 없다.
• 애플리케이션은 schemaname.tablename 포맷으로 된 완전한 테이블 이름을 사용하여 각 사용자가 다른 디폴트 스키마를 갖는 데서 오는 문제를 피한다. 스키마 이름이 SQL 문에 명확히 드러나지 않으면, 연결의 디폴트 스키마로 간주된다. 인증 된 연결의 경우, 사용자 이름이 디폴트 스키마가 된다. 사용자 이름이 지정되지 않으면, 연결이 이루어질 때, 시스템 디폴트 APP 스키마로 간주된다.
• 보안이 중요할 때 데이터베이스를 암호화 하는 문제도 생각해야 한다.
• 계정의 인증을 해제하기 위해서는 패스워드를 null로 설정한다. 예: CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.Jane',null)
• 사용자의 인증을 해제하려면, 그 사용자 이름을 제외하고 권한 리스트를 다시 만든다.

Q: Network Server를 설정하여 자바 보안 매니저 하에서 실행하는 방법은?

A: Derby와 Network Server는 자바 보안 매니저 하에서 실행하기 위해서 특정 액세스 권한이 허용되어야 한다. 이러한 권한은 Network Server가 시작될 때 명령행에 지정된 특별 정책에 리스팅 될 수 있다. 그 다음에 나오는 정책 파일에는 필요한 기본 권한들이 나열된다. 정책 파일(nwsvr.policy)을 만들고, Network Server를 시작할 때 다음과 같은 두 개의 옵션들을 지정한다:

• -Djava.security.manager - 디폴트 보안 매니저를 호출한다.
• -Djava.security.policy=nwsvr.policy - Network Server와 Derby가 올바르게 실행되는데 필요한 액세스를 허용한다.

					
//Recommended set of permissions to start and use the Network Server. 
//  Assumes the Java System variable ${derby.base} is set to the directory that  
//     contains all the derby jars.  Restrict access to this directory!
// Assumes all connections will be from localhost
// Assumes the database is under the directory ${derby.system.home}.
// Fine tune based on your environment settings
grant codeBase "file:${derby.base}/-" {
permission java.io.FilePermission "${derby.system.home}", "read";
permission java.io.FilePermission "${derby.system.home}${/}-", "read, write, delete";
permission java.io.FilePermission "${user.dir}${/}-", "read, write, delete";
permission java.util.PropertyPermission "derby.*", "read";
permission java.util.PropertyPermission "user.dir", "read";
permission java.lang.RuntimePermission "createClassLoader";
permission java.net.SocketPermission "localhost", "accept";
};

java -Djava.security.manager -Djava.security.policy=nwsvr.policy 
     -Dderby.base=/opt/derby/lib
    org.apache.derby.drda.NetworkServerControl -h localhost start

					
permission java.net.SocketPermission "*.myOwnDomain.com", "accept";

					
java -Djava.security.manager -Djava.security.policy=nwsvr.policy 
     -Dderby.base=/opt/derby/lib
    org.apache.derby.drda.NetworkServerControl -h 0.0.0.0 start

Network Server를 사용할 때 보안 관련 기타 고려 사항

• Network Server를 호스팅 하는 머신을 보안화 한다.
• 데이터베이스 파일과 디렉토리로 액세스를 제한한다.
• Network Server가 리스닝 하는 포트를 변경한다.
• Derby 데이터베이스 파일을 암호화 한다.
• Derby BUILTIN 인증 프로바이더 또는 기타 시스템을 사용하여 사용자 인증과 권한을 설정한다.
• SSL이나 기타 기술을 사용하여 네트워크 전송을 암호화 한다.

퍼포먼스

Q: 캐시 히트를 향상하고 I/O를 줄이도록 Derby를 튜닝하는 방법은?

A: Derby에 사용할 수 있는 데이터 캐시 사이즈를 늘려서 많은 양의 데이터를 핸들하는 시스템의 경우 퍼포먼스를 높이고 I/O를 줄일 수 있다. 퍼포먼스에 맞게 캐시를 사이징하는 목적은 pageCache를 설정하여 OutOfMemory 예외(OOMs)를 피하면서 전체 데이터베이스 크기까지 가능한 많은 데이터를 보유하도록 하기 위해서이다. 데이터베이스에 있는 데이터의 대략적인 양은 seg0 디렉토리에 있는 데이터 파일의 총 크기에서 얻을 수 있다. 파일 사이즈 합계는 언제나 데이터베이스에 있는 모든 기록의 총합을 초과한다. 이 파일들에는 여유 공간이 있기 때문이다. 총 데이터 파일 사이즈를 기록하기 전에 데이터베이스를 압축하면 에러를 최소화 할 수 있다. 훨씬 더 작은 캐시가 더 좋은 퍼포먼스를 보이기 때문에 위에 나온 값 보다 큰 pageCache을 사이징 하는 것에는 거론 할 것이 없다.

캐시를 최적으로 사이징 하려면 반복적인 테스팅을 통해서 증가된 캐시가 퍼포먼스를 향상시키는지, JVM(최대 메모리 힙)에 사용할 수 있는 메모리를 초과하지는 않는지 등을 확인해야 한다. 너무 큰 Derby pageCache는 JVM 충돌을 일으킬 수 있다. 다음 요소들의 균형을 맞춰서 OutOfMemory exceptions (OOMs)를 피하도록 한다:

• 머신 상의 물리적 메모리. JVM은 물리적 메모리에 맞아야 한다.
• jvm (-Xmx )에 허용된 최대 힙 크기
• Derby pageCache ( pageCache * avg. pageSize)의 크기

문제 해결 섹션의, Derby를 실행할 때 OutOfMemory 예외를 피하는 방법은? 부분을 참조하라.

위로

일반적인 사용법/기능 (기초)

Q: 스키마는 데이터베이스와 어떻게 다른가?

A: Derby 데이터베이스는 스키마들의 그룹으로서, 각각 고유의 테이블 세트를 갖고 있고, 이 모든 것이 같은 데이터 사전(SYS 스키마의 시스템 테이블)에 의해 정의된다. 디스크 상에서, 데이터베이스는 데이터 파일 세트이고(seg0 디렉토리에 위치), 트랜잭션 로그 파일 세트(log 디렉토리)이다. 트랜잭션은 데이터베이스를 확장할 수 없지만, 같은 데이터베이스에서 스키마를 확장할 수 있다. "Derby 시스템에서 한 개 이상의 데이터베이스로 애플리케이션을 연결하는 방법은?" 부분을 참조하라.

Derby는 스키마를 구현하여 하나의 DB 안에 여러 네임스페이스를 제공한다. 이들은 관련 테이블들을 하나의 논리적 단위로 그룹핑 하는데 사용된다. 스키마와 관련된 개별 디스크 파일들은 없다. 같은 데이터베이스에 있는 모든 스키마들은 같은 데이터 사전과 트랜잭션 로그를 공유한다. 하나의 SQL 문에서 여러 스키마를 참조할 수 있고 같은 연결 안에서 실행될 수 있다. (개방이 필요 없다.) 같은 데이터베이스의 스키마들 간 SQL 조작은 트랜잭션 방식이다.

Q: 특정 값을 칼럼에 삽입한 후에, Derby 아이디 칼럼을 위해 만들어진 값에서 중복 키 오류(ERROR 23505)를 피하려면 어떻게 해야 하는가?

A: 주: 데이터를 아이디 칼럼에 삽입하는 기능은 Version 10.1.2.1에 도입되었다. 초기 버전에는 이 기능이 없다. 아이디 시퀀스를 재설정 하여, 직접 삽입한 값들에 맞추는 기능은 10.2 이전 버전에서는 사용할 수 없다.

유일 값이 필요한 아이디 칼럼에 값을 직접 삽입하는 것은 Derby Zero Administration 시스템에서 벗어난 것이다. 값 생성기가 할당했던 마지막 숫자에 기반하여 아이디 시퀀스를 증가시키고, 직접 삽입한 값은 인식하지 못한다. GENERATED BY DEFAULT 유형의 아이디 칼럼이 중복 값을 발생시키기 때문에, 이 칼럼에 제약 조건을 적용하면, 직접 삽입된 값이 아이디 시퀀스의 일부로서 나중에 생성될 경우 삽입 오류가 생기게 된다. 이 문제는 다음 두 가지 방법을 사용하여 해결된다:

• 값을 중첩시키지 않기: 오버랩 되지 않는 범위로 값들이 나뉘도록 디자인 한다. 예를 들어, 소스 A에서 온 기록들은 범위 1에서 백만이고, 이 테이블에서 생성된 값의 범위는 백만에서 2백만이고, 소스 c에서 온 기록들은 2백만 보다 크다. 개별 시퀀스의 시작 값과 시퀀스가 증가시키는 값들은 칼럼이 만들어 질 때 지정될 수 있다.
• 충돌하는 값들을 교차시키기: 시퀀스에서 만들어진 값은 삽입이 실패하더라도 증가한다. 생성된 값이 기존 값과 충돌하지 않고 삽입이 성공할 때까지 실패한 삽입 문을 재시도 할 수 있다.

Version 10.2에는 ALTER TABLE 명령어를 사용하여 아이디 시퀀스를 재시작 하는 기능이 있다. 문제가 발생하면, 칼럼에 있는 가장 큰 값 보다 큰 재시작 값이 다음 신택스로 지정될 수 있다.

ALTER TABLE <tableName> 
   ALTER COLUMN <identity ColName> 
   RESTART WITH <integer-constant>

Q: Derby 시스템에 있는 한 개 이상의 데이터베이스로 애플리케이션을 연결하는 방법은?

A: 하나의 애플리케이션에 다른 데이터베이스에 대해 다중 연결을 하는 것이 가능하다. 하지만, 인스턴스/커넥션은 SQL과의 크로스 데이터베이스 조작과 관련하여 서로를 인식하지 못하고 있다. 두 개의 데이터베이스/커넥션 간 조작은 애플리케이션 레벨에서 이루어져야 하고(하나의 SQL 문이 아님), 결과는 알맞은 위치에 디스플레이 되어야 한다.

예를 들어, 데이터베이스 A의 테이블 One을 한 어레이로 읽어올 수 있고, 데이터베이스 B의 테이블 Two를 또 다른 어레이로 읽어올 수 있다. 이 어레이에서 데이터 레코드를 순환하고 필요할 경우 값을 변경하면, 그 데이터는 원래 데이터베이스와 테이블에 작성된다. 반대로, 같은 데이터베이스의 두 개의 다른 스키마에 테이블 One과 테이블 Two를 만들면 이 조작은 싱글 트랜잭션 내에서 SQL을 사용하여 수행될 수 있다.

Q: 데이터베이스에 테이블의 이름을 나열하는 방법은?

A: 테이블들은 시스템 테이블 SYSTABLES에 나열된다. 완전한 테이블 이름에는 테이블이 만들어졌던 스키마가 포함된다. (APP는 디폴트 스키마이다.) 다음 쿼리는 데이터베이스에 있는 모든 사용자 테이블의 완전한 테이블 이름을 나열한다.

select s.schemaname || '.' || t.tablename 
     from sys.systables t, sys.sysschemas s 
     where t.schemaid = s.schemaid
          and t.tabletype = 'T'
     order by s.schemaname, t.tablename

Q: Derby 데이터베이스에서 자바 함수를 만드는 방법은?

A: Derby의 강력한 기능은 자신의 함수를 만들어서 특화된 프로세싱을 수행할 수 있는 기능이다. 함수는 자바로 구현되고, SQL 문의 일부로서 호출되며, 트리거에서 사용되어 상황 별 데이터 조작을 수행할 수 있다. 다음 예제는 Derby에서 사용자 정의 함수를 만드는 과정이다. 이 예제 함수는 BIGINT 값을 Hexadecimal 스트링으로 변환한다. Derby 함수와 프로시저를 만드는 더 많은 예제들은 참고자료 섹션을 참조하라.

데이터베이스 함수를 만드는 기본 단계는 다음과 같다:

• 자바 메소드를 만들어서 원하는 조작을 하고 이들을 JAR 파일에 배치한다.
• JAR 파일을 데이터베이스에 설치(로딩)한다.
• JAR 파일을 포함하도록 데이터베이스 클래스 경로를 설정한다.
• 각 메소드를 호출하도록 함수를 생성(정의)한다.
• 새롭게 정의된 함수를 테스트 한다.

				
// Class supporting Derby Java Stored Procedures and Functions
import java.sql.*;

public class derbyJavaUtils
{
// bigintToHexString: converts a BIGINT value to a Hexadecimal String
public static String bigintToHexString(long myBigint)
    {
        return Long.toHexString(myBigint);
    }
}
         

				

Format: CALL SQLJ.install_jar( 'jarFilePath', 'qualifiedJarName', 0)
  Example: CALL sqlj.install_jar(  'derbyJavaUtils.jar','APP.derbyJavaUtils',0 ) 

    NOTE: In this example the file 'derbyJavaUtils.jar' is in the Derby default directory, derby.system.home.  
       The filepath will needed to be specified if the jarfile is not located in derby.system.home.   
      

				

Format: Call SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('KEY','VALUE')
  Example: CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY (
             'derby.database.classpath', 'APP.derbyJavaUtils')
         

				

Example: CREATE FUNCTION app.bigintToHexString(hexString bigint)
RETURNS VARCHAR(16)
PARAMETER STYLE JAVA NO SQL
LANGUAGE JAVA 
EXTERNAL NAME 'derbyJavaUtils.bigintToHexString'
         

				

Example: select CONGLOMERATENAME, bigintToHexString(CONGLOMERATENUMBER) 
           from SYS.SYSCONGLOMERATES
         

Q: 데이터 테이블용 파일 이름을 어떻게 찾는가?

A: SYSCONGLOMERATES 시스템 테이블은 Derby 데이터베이스에 있는 데이터 객체들과 관련된 물리적 파일들을 참조한다. 이 파일 이름은 16 진법 스트링 구현으로서 만들어진다. 데이터베이스의 테이블에 있는 모든 사용자 테이블에 대한 파일 이름들을 나열하려면, Java function FAQ의 bigintToHexString 함수를 만들고 다음 쿼리를 실행한다:

select  TABLENAME, 'C' ||  bigintToHexString(CONGLOMERATENUMBER) ||  '.dat' 
 from SYS.SYSCONGLOMERATES a, SYS.SYSTABLES b
 where a.TABLEID = b.TABLEID AND b.TABLETYPE <> 'S' ;

위로

문제 해결

Q: Derby용 개발 환경을 설정하는 방법은?

A: 개발 및 테스트 환경에서 아래 보이는 Derby 속성들을 설정하여, Derby 에러 로그가 자동으로 제거되지 않도록 하고, 모든 에러들과 경고들이 기록되도록 한다. 이러한 설정이 사용되면 Derby는 더 이상 Zero Administration이 아니기 때문에, 로그 파일의 크기를 관찰해야 한다. Zero Administration이 중요한 실행 환경에서 이 속성들을 절대 사용하지 말라.

이러한 속성들을 설정하는 가장 간단한 방법은 derby.system.home 디렉토리에 derby.properties 라고 하는 파일을 만드는 것이다. (이는 Derby errorlog logfile을 포함하고 있는 같은 디렉토리이다.) 또는, 자바 명령행에 -D 매개변수들을 사용하여 각 속성들을 설정할 수 있다. 속성들이 적용되도록 하려면 Derby를 재시작한다. 아래는 개발 및 테스트 환경에서 사용할 주석이 달린 속성 파일이다.

				
#           Top of Sample File 
# This is a sample Derby properties file provided to show 
#   setting properties which are useful for development and 
# troubleshooting 
# 
# -- Append to the log file rather than overwriting it 
# - manually remove the derby.log when it becomes large
derby.infolog.append=true 
# 
# -- Log all errors/messages of any severity (will list deadlocks)
derby.stream.error.logSeverityLevel=0 
# 
# -- Log all lock timeouts with additional trace information
derby.locks.monitor=true 
# 
# - List transaction information on victim and survivor transactions # for both lockTimeouts
#     for both lockTimeouts and Deadlocks
derby.locks.deadlockTrace=true 
#           End of Sample File
         

Q: Derby를 실행할 때 OutOfMemory 예외를 피하는 방법은?

A: 다음 섹션에서는 Derby 메모리 사용법을 설명하고 Derby와 JVM을 사이징하여 OutOfMemory 예외를 피하는 방법을 설명하고 있다.

Derby 메모리 사용에 관련된 요소들

Derby 퍼포먼스 때문에 골치가 아프고, OutOfMemory exceptions (OOMs)를 만났다면, 가장 먼저 Derby pageCache를 조정해야 한다. pageCache에 안전하게 할당할 수 있는 메모리는 많은 요소들에 의존한다. 물리적 메모리, 평균 pageSize, JVM 최대 힙 사이즈(maxHeap)가 주 요소들이다. 기본적으로 JVM 최대 힙 사이즈의 비율로 pageCache에 할당할 페이지의 수를 계산한다.

JVM 최대 힙 사이즈

JVM 최대 힙 사이즈(maxHeap)은 자바 매개변수 -Xmx#m을 사용하여 설정된다. 여기에서 #은 힙에 할당할 최대 Mb의 수이다. (예를 들어, 128 Mb maxHeap의 경우 java -Xmx128m). 지정된 JVM 최대 힙 사이즈가 머신의 총 물리적 메모리 보다 작아야 한다.

JVM MaxHeap과 Derby PageCache

Cloudscape 4.0 (Derby의 전신)과 Java 1.4.0을 사용한 테스트를 통해, heapSize 대 Cloudscape pageCache pageCache 비율을 20:1로 하는 것이 안전하다는 결과를 얻었다. 이 비율은 활성 애플리케이션을 지원하고 많은 애플리케이션들이 더 작은 비율로도 잘 작동하도록 한다. 초당 많은 트랜잭션을 핸들 하는 애플리케이션은 더 큰 JVM maxHeap과 Cloudscape pageCache의 비율로 OutOfMemoryExceptions를 경험했을 것이다. OOM을 경험했다면, 스트레스 테스팅을 통해 최적의 비율을 판단해야 한다. JVM 대 pageCache 비율을 20:1로 시작하고, 장기 실행 스트레스 테스트를 수행하여 메모리 사용이 안정화 되는 때가 언제인지를 파악한다. 어떤 OOM도 나타나지 않으면, 허용할 만한 임계치에 이를 때까지 또는 애플리케이션이 OutOfMemory 예외를 만날 때까지 더 작은 비율로 추가 테스트를 수행한다. 경량 애플리케이션들은 2.5:1의 비율로 실행될 수 있다. Derby Version 5.1 (1000 pageCache [= 4 MB cache]와 64K maxHeap)은 16:1 r비율이고, 대부분의 애플리케이션에서 잘 작동한다. 최상의 비율은 OOM 없이 적절한 퍼포먼스를 보이는 것이다.

PageCache: 계산법

Derby pageCache의 크기는 데이터베이스에 사용된 평균 페이지 크기와 derby.storage.pageCacheSize 속성 설정으로 결정된다. pageCache는 Derby 페이지 캐시가 보유한 최대 페이지 수를 지정한다. pageCache가 사용할 메모리의 양을 계산하려면, pageCache를 데이터베이스의 평균 페이지 사이즈에 곱한다. (derby.storage.pageSize 속성 관련 문서 참조). 데이터베이스의 모든 테이블에 디폴트 페이지 크기인 4K를 사용하면 계산법은 (pgSz = 4k) x (pageCache 설정)이다.

JVM Heap대 PageCache 비율: 계산법

V1.4 JVM과 이전 버전에서 실행하는 Cloudscape Version 4.0에 대한 디폴트 heap:pageCache 비율(maxHeap이나 pageCache가 설정되지 않았을 경우)은 400:1 (64M / ( (40*4K)/1000)이다. Version 5.0의 경우, pageCache 크기는 40에서 1000 페이지로 증가했기 때문에, 디폴트 비율도 16:1 (64M / ( (1000*4)/1000 ) )로 수정했다. 이 비율은 활성 애플리케이션에는 너무 작고, OOM이 Version 5.0을 사용할 때 발생할 수 있다.

Q: 내 모든 테이블과 인덱스의 무결성을 입증하는 방법은?

A: Derby의 트랜잭션 로깅과 복구 시스템은 머신을 보호하고 데이터베이스 충돌을 방지한다. 하지만, 하드웨어 문제(I/O 시스템 오류)가 있고, 데이터베이스가 이중 부팅되었다면, 테이블과 인덱스의 내부 무결성을 확인해야 한다. Derby는 시스템 함수 SYSCS_UTIL.SYSCS_CHECK_TABLE을 제공하여 테이블 인덱스의 무결성을 검사한다. 이 함수는 데이터 사전에 대한 쿼리의 일부로서 실행되어 데이터베이스에 있는 각 사용자 테이블을 검사한다. 문제가 발견되면, 쿼리가 예외 없이 완료될 때까지 문제 테이블들을 제외하고 쿼리를 재실행 해야 한다. 다음은 그 과정이다.

1. IJ 또는 기타 쿼리 메커니즘을 사용하여 다음 쿼리를 실행한다.

   SELECT schemaname || '.' || tablename as TableName, SYSCS_UTIL.SYSCS_CHECK_TABLE(schemaname, tablename) AS OK FROM sys.sysschemas s, sys.systables t WHERE s.schemaid = t.schemaid and t.tabletype = 'T';

   
   
2. 문제가 발견되면, 남아있는 테이블에 쿼리를 실행하지 않고 중지한다. 테이블의 이름은 예외에 나타난다. 문제가 인덱스와 함께 있다면, 인덱스 이름을 주목하라. 문제 테이블을 제외하고 쿼리를 재실행 한다.

   SELECT schemaname ||'.' || tablename as TableName, SYSCS_UTIL.SYSCS_CHECK_TABLE(schemaname, tablename) AS OK FROM sys.sysschemas s, sys.systables t WHERE s.schemaid = t.schemaid and t.tabletype = 'T' and tablename NOT IN ("<tableX>");

   
   
3. 더 많은 문제들이 발견되면, 쿼리가 예외 없이 끝날 때까지 NOT IN 리스트에 계속해서 추가한다. tablename NOT IN ("CITIES","FLIGHTS") 구절과 비슷할 것이다. 데모 데이터베이스 toursdb에 대해 실행하면 결과는 다음과 같다.

   ij> SELECT schemaname ||'.' || tablename as TableName, SYSCS_UTIL.SYSCS_CHECK_TABLE(schemaname, tablename) AS OK FROM sys.sysschemas s, sys.systables t WHERE s.schemaid = t.schemaid and t.tabletype = 'T' and tablename NOT IN ("CITIES","FLIGHTS"); TABLENAME |OK -------------------------------- -------------------- APP.AIRLINES |1 APP.COUNTRIES |1 APP.FLIGHTAVAILABILITY |1 APP.MAPS |1 APP.FLIGHTS_HISTORY |1 5 rows selected

   
   

위로

릴리즈 정보

Q: IBM Cloudscape, Version 10.1의 새로운 기능은 무엇이 있는가?

A: IBM Cloudscape 10.1에는 Apache Derby 10.1 릴리즈가 포함되어 있고, Apache Derby의 두 번째 상용 버전이 된다. Version 10.0의 모든 장점과 기능들을 물려받았을 뿐만 아니라, Version 10.1에는 다음과 같은 내용이 들어있다.

• JDBC API defined for the Connected Device Configuration (CDC) / Foundation Profile (FP)를 위해 정의된 JDBC API인 JSR 169 지원. Java 2 Platform, Micro Edition (J2ME) CDC/FP 환경에서 실행할 때 org.apache.derby.jdbc.EmbeddedSimpleDataSource 클래스를 사용한다.
• Derby Network Server와 사용되는 오픈 소스 라이브러리인 Derby Network Client. Network Server, Version 10.1은 IBM DB2 JDBC Universal Driver를 여전히 지원하지만, Derby Network Client가 표준 클라이언트 라이브러리가 될 것이다.
• Derby Network 클라이언트를 사용할 때 XA 분산 트랜잭션을 지원한다. Java Transaction API (JTA)를 구현하는 분산 J2EE 환경에서 J2EE Resource 매니저에서 Derby를 구현할 때 org.apache.derby.client.jdbc.ClientXADataSource 클라이언트 클래스를 사용한다.
• 소프트 업그레이드: upgrade=true를 설정하지 않고 10.1 버전을 사용하여 Derby 10.0에서 만들어진 데이터베이스로 액세스 가능하고, 구 버전을 사용하여 데이터베이스에 액세스 할 수 있다. 하지만 확정 업그레이드가 될 때까지는 몇몇 새로운 기능은 사용할 수 없다.
• JDBC 3.0 Updatable ResultSet API 지원
• SQL 동의어
• SQL Date/Time을 계산하는 함수
• SQL intercept/except
• 값을 각 칼럼으로 반입 또는 삽입하는 기능
• 테이블 압축
• Cloudscape, Version 5에서 IBM Cloudscape, Version 10.x (2005년 8월 말부터 developerWorks에서 다운로드 가능) 까지 업그레이드를 지원하는 마이그레이션 툴 (참고자료 .)

Q: 10.1 버전에 새로운 클라이언트 드라이버 라이브러리가 릴리즈 된 이유는?

A: Derby Network Client (derbyclient.jar)는 Derby Network Server를 위한 새로운 클라이언트 측 라이브러리이다. DB2 JDBC Universal Driver와 마찬가지로, 원격 머신이나 프로세스에서 Derby Network Server에 있는 Derby 데이터베이스로 액세스를 제공한다. 전 버전과는 달리, Network Client는 오픈 소스 코드이고, Derby Network Server와 더욱 잘 통합된다. 다음은 향상된 부분이다:

• 사용자 이름과 패스워드는 인증이 사용될 경우에만 필요하다.
• 일부 데이터베이스 경로에 사용된 슬래시나 콜론 문자를 없앨 때 더 이상 인용 부호가 필요 없다.
• URL 커넥션 애트리뷰트는 독립적으로 배치되고, 한정자(세미콜론)을 사용한다.
• 클라이언트 라이브러리에 대한 개별 라이센스가 없다. (Apache Derby 소프트웨어와 마찬가지로, Apache 라이센스로 사용할 수 있다.)

Derby Network Server Version 10.1은 Derby Network Client와 DB2 JDBC Universal Driver를 지원한다. 앞으로는 Network Server도 Derby Network Client 라이브러리를 사용해야 한다. 예를 들어, Network Client에만 Network Server XA datasource, org.apache.derby.client.jdbc.ClientXADataSource 가 포함된다.

Universal Driver에서 Network Client로 전향하려면 다음 사항이 요구된다:

• derbyclient.jar 파일을 배포하여 이를 db2jcc.jar와 db2jcc_license_c.jar 대신 CLASSPATH에 둔다.
• 애플리케이션을 업데이트 하여 새로운 드라이버(org.apache.derby.jdbc.ClientDriver)를 로딩한다.
• 데이터베이스 연결 URL을 더 간단한 신택스로 바꾼다:
  
  

  jdbc:derby://<server>[:<port>]/<databaseName> [;<URL attribute>=<value>[;...]]

  
  

Q: IBM Cloudscape, Version 10.0은 무엇인가?

A: IBM Cloudscape 10.0은 IBM Apache Derby의 상용 릴리즈로서, 작은 풋프린트를 가진, 멀티 유저, 표준 기반의 관계형 데이터베이스로서, 자바 애플리케이션과 서버에 삽입하기에 알맞다. Derby와 IBM Cloudscape의 핵심 기능은 같다. Derby는 완벽한 기능을 갖춘 JVM에서 실행되기 때문에, 같은 애플리케이션이 많은 하드웨어 플랫폼에서도 변경되지 않고 실행된다.

Derby는 SQL-92E (entry) 표준을 지원하고 SQL-99의 일부를 지원한다. Derby API는 JDBC이다. Derby는 어떤 관리도 필요 없다(zero admin); 따라서 애플리케이션과 별도로 데이터베이스를 설치하거나 관리할 필요가 없다. ‘설치만 하면 끝(Install it and forget it)’ 이 성공적인 임베디드 컴포넌트의 핵심 목표이다.

기사의 원문보기

• A compendium of Cloudscape frequently asked questions

참고자료

교육

• Cloudscape Technical Support Technotes
  
  
• Cloudscape technical overview (developerworks, August 2005)
  
  
• Cloudscape technical resource center
  
  
• Cloudscape and ODBC (developerWorks, August 2005)
  
  
• Apache Derby Project home page.
  
  
• Derby Functions and Procedures
  
  
• Java Security Manager Policy File Syntax
  
  
• Java Security Specification: Permissions
  
  
• Use Derby in a J2EE Server environment
  
  
• developerWorks DB2 zone
  
  

제품 및 기술 얻기

• Migration Tool
  
  
• IBM DB2 JDBC Universal Driver
  
  
• Download free modules
  
  
• Technical support
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks blogs
  
  

필자소개

아티클 순위

의견

위로

목차

• 목차
• 일반 질문
• 설치와 설정
• 일반적인 사용법/기능 (기초)
• 문제 해결
• 릴리즈 정보
• 참고자료
• 필자소개
• 의견