• The Transactions of the Korea Information Processing Society
• /
• v.7 no.8S
• /
• pp.2735-2747
• /
• 2000

클라이언트/서버 데이터베이스 시스템에서 로깅 기법을 사용하는 기존 회복 기법은 서버에서만 전체 로그를 관리한다. 이는 잠재적으로 각 클라이언트에서 수행되는 트랜잭션에 대한 로그 레코드의 전송 비용을 내포하고 있고, 네트워크 트래픽을 증가시킨다. 본 논문에서는 로그 레코드의 전송 비용을 제거하기 위해서 클라이언트 기반 로깅(client-based logging)을 지원하고, 중복된 before-image를 제거하고 재수행 전용 로그(redo-only log)만을 로깅하는 방법을 제안한다. 그리고 클라이언트 파손 시 클라이언트에서 자치적으로 한번의 후방향 클라이언트 로그 분석을 이용한 재수행 회복을 하고, 서버 파손 시 각 클라이언트에서는 병행적으로 후방향 클라이언트 로그 분석을 이용하여 회복해야 하는 페이지의 after-image만을 서버에 전송하며, 서버에서는 수신된 after-image와 후방향 서버 로그 분석을 이용하여 재수행 회복을 수행한다.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2003.05c
• /
• pp.1635-1638
• /
• 2003

이질적인 데이터베이스간의 중복 데이터 일관성을 유지문제를 해결함으로써 기존의 디스크 기반 범용 데이터베이스를 사용하는 시스템의 방대한 데이터들을 주기억장치 상주형 데이터베이스에 중복 저장함으로써 디스크 I/O 와 관련된 지연 시간 없이 빠른 성능 향상을 기대할 수 있으므로 네트워크상의 불특정 다수의 서비스 형태에 빠른 응답 시간과 처리 시간을 제공 할 수 있다. 본 본문에서 제시하는 중복 데이터 일관성 유지 기법은 디스크 기반 범용 데이터베이스의 REDO LOG를 참조하여 갱신트랜잭션에 관한 로그를 주기억 상주형 데이터베이스에 적용하도록 설계하고 두 데이터베이스간의 일관성 유지를 위해 수행되는 기능들이 성능 향상을 위한 목적을 위배하지 않으면서 이질적인 데이터베이스간의 일관성을 보장하도록 한다. 또한 두 데이터베이스의 성능 차이로 인해 발생할 수 있는 문제점들을 해결하고, 시스템 붕괴 시를 고려하여 유지되지 못한 데이터 일관성에 대해서도 복구 후에 일관성 유지를 가능케 하는 기법을 제공한다.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2004.11a
• /
• pp.19-22
• /
• 2004

분산 시스템 환경에서 여러 시스템에 정보를 전송하기 위한 방법으로 최근 EAI 의 DB Trigger 및 Redo Log 등을 이용한 실시간 데이터 통합 방식을 적용해 왔다. 그러나 기업에서 순차적인 배치 프로세스들을 통해 처리하는 대량의 데이터에 대해 기존의 EAI 의 데이터 통합 방식을 사용할 경우 모든 변경 건수에 대해 이벤트가 발생하여 Source 시스템의 부하 및 통합 성능상의 문제점이 있다. 본 논문에서는 순차적인 배치 프로세스들을 EAI 의 프로세스 레벨 통합을 적용하여 최종 변경된 데이터에 대해서만 통합하도록 하여 통합 처리 시간을 단축할 수 있는 방법을 제시하고자 한다.

• Journal of KIISE:Databases
• /
• v.28 no.3
• /
• pp.494-511
• /
• 2001

In the environment that database management systems manage disk spaces for storing databases directly, this paper proposes a correct and efficient scheme of performing pending actions for the removal of database files. As for performing pending actions, upon performing recovery, the recovery process must identify unperformed pending actions of not-yet-terminated transactions and then perform those actions completely. Making the recovery process identify those actions through the analysis of log records in the log file is the basic idea of this paper. This scheme, as an extension of the execution of transactions, fuzzy checkpoint, and recovery of ARIES, uses the following methods: First, to identify not-yet-terminated transactions during recovery, transactions perform pending actions after writing 'pa_start'log records that signify both the commit of transactions and the start of executing pending actions, and then write 'eng'log records. Second, to restore pending-actions-lists of not-yet-terminated transactions during recovery, each transaction records its pending-actions-list in 'pa_start'log record and the checkpoint process records pending-actions-lists of transactions that are decided to be committed in 'end_chkpt'log record. Third, to identify the next pending action to perform during recovery, whenever a page is updated during the execution of pending actions, transactions record the information that identifies the next pending action to perform in the log record that has the redo information against the page.