KR950010485B1 - 전전자 교환기에서 분산릴레이션의 생성에 대한 데이타베이스 스키마 관리방법 - Google Patents

Abstract

내용 없음.

Description

전전자 교환기에서 분산릴레이션의 생성에 대한 데이타베이스 스키마 관리방법

제 1 도는 본 발명의 내용을 포함하는 전전자 교환기 데이타베이스 관리시스템의 분산 구조도.

제 2 도는 스키마 관리 기능을 구현하기 위한 블럭간의 구성과 메시지 흐름을 나타내는 구조도.

제 3 도는 본 발명의 분산 릴레이션의 생성에 대한 스키마 관리의 전체적인 흐름도.

제 4 도는 분산 릴레이션의 생성에 대해 분산 정보를 생성하고 저장하는 상세한 흐름도.

본 발명은 전전자 교환기의 데이타베이스 관리시스템(DBMS)에 있어서, 분산 릴레이션에 대한 데이타베이스 스키마 관리방법에 관한 것이다.

기존의 전전자 교환기의 데이타베이스 스키마 관리 기법에서는 로컬 릴레이션에 대한 스키마 관리만 가능하고 분산 릴레이션에 대한 스키마 관리 기능이 없었다. 그래서 한번 데이타베이스가 만들어지면, 교환기의 운용중에 분산 릴레이션의 생성이나 삭제등이 요구될 때는 항상 호스트 상에서 분산된 릴레이션이 존재해야하는 모든 프로세서에 대해 새로이 데이타를 등록하여 데이타 생성기를 통해 데이타 화일을 제작한 후 교환기 시스템에 로딩하는 가정을 거쳐야 한다. 따라서 분산 릴레이션이 존재해야할 모든 프로세서의 데이타베이스 제작시에 필요한 시간과 오버헤드(overhead) 때문에 그대마다 즉시 변경 요구 사항이 데이타베스에 반영될 수 없었고, 어느 정도의 요구가 발생했을 때 다시 데이타베이스 화일을 제작하여 그 요구를 반영하였다. 이러한 과정은 새로운 기능을 시스템에 적용하기 위해서 호스트 상에서의 사전 작업과 그에 따른 시간을 필요로 하며, 또한 데이타베이스 화일의 로딩을 위한 일시적인 시스템 운용의 중단을 초래했다.

따라서, 상기 종래기술의 문제점을 해결하기 위하여 안출된 본 발명의 목적은, 사용자의 기능 개발 및 변경에 따라 분산 릴레이션의 생성이 요구될 때 교환기 시스템 운용중에 이 요구를 받아들여 스키마를 변경하도록 하여 전체 시스템의 수행에 지장이 없이 새로운 기능의 적용을 빠르고 쉽게 할 수 있도록 한 데이타베이스의 스키마 관리방법을 제공하는데 있다.

상기 목적을 달성하기 위하여 본 발명은 분산된 호처리 기능을 담당하는 프로세서(ASP)와, 집중화된 호 처리를 수행하는 프로세서(INP,NTP)와, 운용 및 보전에 관련된 집중화 기능을 수행하는 프로세서 (OMP, MMP)를 구비하며, 상기 각 프로세서에 데이타베이스 관리시스템(DBMS)를 탑재하도록 한 전전자 교환기에 적용되는 분산릴레이션의 생성에 대한 스키마(Schema) 관리방법에 있어서, 분산 릴레이션의 생성요구가 발생하면, 데이타 변경과 관련된 각 프로세서들의 데이타 변경에 따른 메모리 할당이 가능하게 됨에 따라 각 프로세서들의 스키마 관리기에게 질의어를 통해 입수되었던 데이타 변경 정보를 전송하는 제 1 단계와, 상기 제 1 단계수행후, 각 프로세서들의 스키마 관리기에서 전송되어온 정보에 따라 스키마 생성을 수행하고 분산테이블을 작성하는 제 2 단계와, 상기 제 2 단계 수행후, 각 프로세서에서 모두 성공하면 스키마 변경중에 발생한 로그 내용에 따라 모두 성공하면 스키마 변경중을 발생한 로그 내용에 따라 디스크에 백업을 하며, 하나의 프로세서라도 스키마 변경에 실팩하게 되면 나머지 프로세서들은 로그 내용을 참조하여 스키마를 복구하고 종료하는 제 3 단계를 구비하여 수행하는 것을 특징으로 한다.

이하, 첨부된 도면을 사용하여 본 발명의 일실시예를 상세히 설명한다.

제 1 도는 전전자 교환기 시스템에 적용된 분산 릴레이션을 위한 스키마 관리 기능을 제공하도록 구성된 분산 구조를 갖는 메인 메모리 데이타베이스 관리시스템(DBMS ; Data Base Management System)의 구조도이다.

도면에 도시한 바와같이, 전전자 교환기는 ASS(Access Switching Subsystem), INS(Interconnection Network Subsystem) 그리고 CCS(Central Control Subsystem)의 3개의 서브시스템으로 구성된다.

ASS는 분산된 호처리기 기능을 수행하는 ASP(Access Switching Processor)를 구비하고, INS는 징중화된 호처리 기능 부분을 수행하는 INP(Interconnection Newtwork Processor)와 NTP(Numder Translation Processor)를 구비하여, CCS는 운용 및 보전에 관련된 집중화 기능을 수행하며, OMP(Operation and Maintenance Processor)와 MMP(Man-Machine Processor)를 구비한다.

데이타베이스간 존재하는 전 전 프로세서에는 스키마 관리기인 SM(Schema Manager)이 있는 DBSG(Data Base Supporting Croup)를 포함하는 DBMS가 존재한다. 위의 프로세서들 중에서 OMP의 DBMS는 DBBG(Data Base Backup Group), DBSG, DBTG(Data Base Transaction Group), 그리고 DBKG(Data Base Kernel Croup)의 4개 블럭으로 구성되고, MMP의 DBMS는 DBQG(Data Base Query Group), DBSG, DBTC 그리고 DBKG의 4개의 블럭으로 구성되며, 나머지 프로세서들은 DBSG, DBKG, DBKG 3개의 블럭으로 구성된다. DBSG는 사용자 정합 기능자 DBMS간의 통신 기능을 수행하고, DBQG는 MMP를 통해 들어오는 데이타베이스 질의어에 대한 처리를 수행한다. DBBG는 분산 데이타의 변경되어, 데이타 백업 및 회복 기능을 수행하고, DBTG는 트랜잭션 처리기능을 수행하며, DBKG는 실제로 데이타베이스를 검색, 변경, 삽입 그리고 삭제하는 기능을 수행한다.

제 2 도는 전전자 교환기 시스템에서 분산 릴레이션의 생성을 위한 스키마관리 기능을 구현하기 위해 관련 블럭간의 구성 및 메시지의 흐름을 나타낸 구조도이다.

운용자 터미널의 입출력 정합부(MMI)로부터 데이타베이스 질의어를 통해 사용자의 분산 릴레이션 생성 요구가 들어오면(1), MMF의 DBQG(DB Query Group)블럭에서는 기존의 스키마를 참보하여 요구 내용을 검증하고 분산 릴레이션의 존재해야 하는 각 프로서서의 DBSG블럭에 있는 스키마 관리기로 스키마 변경에 따른 메모리 할당을 요구하고(2), 각 프로세서의 스키마 괸리기는 스키마 변경에 따른 메모리 할당 가능성 여부를 조사하여 그 결과 메시지를 MMP의 DBQG에서는 사용자로부터 받은 블럭을 전송한다(3).

이때 모든 메시지가 성공이면, DBQG에서는 사용자로부터 받은 분산 릴레이션 정보(릴레이션 식별번호, 매스터(master) 프로세서와 최대 튜플 갯수, 슬레이브(slave) 프로세서와 최대 튜플 갯수등)를 관련 프로세서들로 보내어 스키마 변경을 요구한다(2). 각 프로세서들의 스키마 관리기를 릴레이션 정보를 받아 분석하여 스키마 내용에 따라 정보들을 생성하고, DBKG를 호출하여 실제 데이타베이스 상에 정보등을 저장한다(4). 수행 결과를 DBSG블럭을(5), 다시 DBQC블럭으로 전송한 후(3) 모든 프로세서들에서 스키마 변경이 모드 성공하게 되면 변경 내용은 DBBG를 통해 디스크에 백업된다. 만약 어느 한 프로세서라도 실패하게 되면떤 DBQG의 요청에 의해 스키마 변경이 일어났던 프로센서들은 그 전의 상태를 유지하기 위해 DBQG에서 복구를 수행한다(2).

제 3 도는 전전자 교환기의 데이타베이스 관리 시스템의(DBMS) 구성중 분산 릴레이션의 생성에 대한 스키마 관리 제어의 전체적인 흐름을 나타내는 구조도이다.

DHQG는 분산 릴레이션의 생성 요구로 관련 정보를 항목별로 입력받아 필요한 메모리 양을 계산하여(11) 관련된 모든 프로세서로 스키마 생성을 위한 메모리 할당 요구를 하고(12), DBSG의 스키마 관리기는 요구내용별로 필요한 메모리 확보가 가능한가를 확인하여(13) 그 여부를 DBQG로 전송한다(14). 이때 관련된 모든 프로세서에서 가능하다는 응답이 오면, 각 프로세서의 BDSG에서는 분산 릴레이션에 관한 정보들을 생성하여, 실제 데이타베이스에 저장하고, 로그(LOG)를 생성한다(15). 스키마 변경 완료를 알리는 메시지를 DBQG로 전송하고, DBSG로부터 스키마 복구 요청이 오지 않으면 스키마 변경으로 발생되었던 로그들을 모두 OMP의 DBBG로 보내어 디스크에 백업한다(16). 그러나 만약 정보의 생성과 저장중에 한 프로세서라도 실패하면 DBQG는 DBSG로 복구 요청을 하고, DBSG픈 로그를 참조하여 메모리를 복구한다(17). DBBG로부터 디스크 백업 완료 메시지를 접수함으로써 스키마 변경을 마친다.

제 4 도는 제 3 도에 따른 분산 릴레이션의 생성을 위한 스키마 관리방법중 분산 릴레이션이 존재해야 하는 모든 프로세서에서 관련 정보를 생성, 저장하고 로그를 발생하는 단계(15)의 세부적인 흐름도이다.

DBQG로부터 분산 릴레이션의 생성에 따른 스키마 변경 요구를 받은 프로세서의 DBSG는 프로세서 로드데이타(PLD)라는 실제 데이타베이스에 저장하기 위한 각종 정보를 생성한다. 상기 PLD에는 글로벌 디렉토리(GDIR), 릴레이션 디렉토리(RDIR), 릴레이션 딕셔너리(RDIC)를 비롯하여 릴레이션의 각종 정보를 포함하는 테이블들과 실제 데이타가 저장되어 있다.

DBSG는 그 프로세서가 자신의 데이타베이스로 직전 접근(local access)하거나 다른 프로세서로 원결 접근(local access)을 할 수 있는 모든 릴레이션에 대한 정보인 GDIR 정보를 생성하고, 자신의 프로세서에만 존재하는 릴레이션에 대한 RDIR 정보를 생성하고, RDIR에 존재하는 모든 릴레이션에 대해 그의 애트리뷰트 정보인 RDIC 정보를 생성한다(15-12). 만약 릴레이션의 접근 권한중 트랜잭션 수행시 필요한 잠금 ('look')과 해제('unlock')이 허영된다면 잠금 테이블에 저장될 정보를 생성하고(15-2), 분산 헤더 정보와 분산 테이블 정보를 생성한다(15-3).

이들 정보의 생성을 마치면 DBKG로 메모리 변경을 요구하고, DBKG에서는 요구된 릴렝션의 식별번호를 참조하여, PLD의 GDIR의 특정 위치에 GDIR정보를 저장하고, 잠금 정보는 PLD의 잠금 테이블에 저장한 후 마지막 레코드를 표시하는 특정 레코드의 위치를 조정한다. RDIR정보와 RDIC정보는 미리 잡혀진 여부의 메모리에 저장되고, 실제 데이타들이 저장될 주영역/보조영역(Main Area,/Sub Area)는 계산된 크기만큼 여분의 메모리에 할당되고 메모리의 내용이 초기화된다(15-4).

분산 헤더와 분산 테이블에 대한 정보는 이들을 위해 미리 마련된 여분의 메모리에 특정 기능을 수행하기 위한 2개의 필드들과 함께 저장되는데, 이 특정 필드는 다음과 같다.

첫째, 이 릴레이션을 위한 GDIR의 정보에는 5번째 필드에 분산 헤더의 시작 주소가 저장되는데 만약 이 릴레이션이 삭제되거나, 메모리의 효율적인 관리는 위해 여분의 메모리 상에서 메모리 컴팩션(memory compaction)이 요구될 때 분산 헤더가 메모리 상에서 이동을 함으로써 GDIR의 5번째 필드 값을 수정해야 할 것이다. 이런 필요에 의해 GDIR의 5번째 필드의 주소를 기억해야 함에 따라 분산 해더 정보를 저장하기 앞서 DGIR의 5번째 필드의 주소를 저장한다.

둘째, 분산 릴레이션은 프로세서마다 최대 튜플 갯수가 다르고, 릴레이션 삭제나 메모리 컴팩션시 메모리의 사용 영역과 사용가능 영역을 알기 위해 분산 헤더와 분산 테이블이 차지하는 총 메모리 크기를 저장해야 한다(15-5,15-6).

이들 두 특정 필드가 저장돈후 분산 헤더의 분산테이블을 연속된 메모리 상에 저장한다(15-7). 정보의 생성시 로그를 생성하고 모든 정보들이 실제 데이타베이스에 저장된후 여분의 메모리 내용을 수정한다(15-8). 이의 결과를 DBQG로 전송하는데 모든 프로세서가 성공이면, '성공'을 전송하고(15-9), 한 프로세서라도 실패하면, '실패'를 전송한다(15-10).

따라서, 상기와 같은 처리절차에 수행되는 본 발명은 다음과 같은 효과를 가진다.

첫째, 전전자 교환기 내의 응융 프로그램을 통해서만 분산 릴레이션으로 접근이 가능했으나 온라인 상에서 곧바로 분산 릴레이션의 생성이 가능하게 되어 데이타베이스의 운용상의 융통성을 부여하게 된다.

둘째, 운용자가 온라인 상에서 바로 분산 릴레이션의 생성을 처리할 수 있으므로 사용자가 기능개발을 하면서 변경해야할 분산 릴레이션이 생겼을 때 오프 라인에서 등록 및 생성하는 절차를 밟지 않아도 되므로 사용자의 기능개발이 편리하다.

셋째, 분산 릴레이션의 생성 및 추가시 분산 릴레이션이 존재해야 하는 모든 프로세서의 데이타베이스를 새로이 제작하지 않고도 기존의 데이타베이스에서 운용이 가능하므로 운용상의 오버헤드를 줄이고 시간을 단축한다.

네째, 오프 라인에서 릴레이션을 등록하여 새로운 데이타베이스화일을 제작하게 되면 시스팀에 로딩하기 위해 프로세서의 운용이 잠시 중단되어야 했으나, 스키마 관리가 가능해짐으로버 시스템의 운용이 중단됨이 없이 분산 릴레이션의 생성이 가능하다.

Claims (2)

1. 분산된 호처러 기능을 담당하는 프로세서(ASP)와, 집중화된 호처리를 수행하는 프로세서(INP, NTP)와, 운용 및 보전에 관련된 집중화 기능을 수행하는 프로세서(OMP, MMP)를 구비하며, 상기 각 프로세서에 데이타베이스 관리시스템(DBMS)를 탑재하도록 한 전전자 교환기에 적용되는 분산릴레이션의 생성에 대한 스키마(Schema) 관리방법에 있어서, 분산 릴레이션의 생성요구가 발생하면, 데이타 변경과 관련된 각 프로세서들의 데이타 변경에 따른 메모리 할당이 가능하게 됨에 따라 각 프로세서들의 스키마 관리기에게 질의어론 통해 입수되었던 데이타 변경 정보를 전송하는 제 1 단계 (11 내지 14)와, 상기 제 1 단계 (11 내지 14) 수행후, 각 프로세서들이 스키마 관리기에서 전송되어온 정보에 따라 스키마 생성을 수행하고 분산 테이블을 작성하는 제 2 단계(15)와, 상기 제 2 단계(15) 수행후, 각 프로세서에서 모두 성공하면 스키마 변경중에 발생한 로그 내용에 따라 모두 성공하면 스키마 변경중에 발생한 로그 내용에 따라 디스크에 백업을 하며, 하나의 프로세서라도 스키마 변경에 실패하게 되면 나머지 프로세서들은 로그 내용을 참조하여 스키마를 복구하고 종료하는 제 3 단계(16 내지 17)를 구비하여 수행되는 것을 특징으로 하는 분산릴레이션의 생성에 대한 스키마 관리방법.
2. 제 1 항에 있어서, 상기 제 2 단계(15)는, 분산헤더와 분산테이블에 저장될 정보를 생성하는 단계(15-1내지 15-3)와, 상기 단계(15-1 내지 15-3) 수행후, 분산 헤더와 분산 테이블의 정보의 운용을 위한 제 1 특정 필드(글로벌 디렉토리 5번째 필드의 시작주소)와 제 2 특정 필드(분산 정보의 총크기)를 계산하여 생성하는 단계(15-4 내지 15-5)와, 상기 단계(15-4 내지 15-5) 수행후, 상기 제1 및 제 2 특정필드, 분산헤더 분산테이블을 차례로 지정하는 단계(15-6 내지 15-7)와, 상기 단계(15-6 내지 15-7) 수행후, 여분메모리의 내용을 갱신하고 분산된 모든 메모리에서의 성공여부를 통보하고 종료하는 단계(15-8 내지 15-10)를 구비하여 수행되는 것을 특징으로 하는 분산릴레이션의 생성에 대한 스키마 관리방법.