위에 Chunk가 두 개 표기되어 있는데 실제로는 한 개만 사용 가능합니다.
두가지 방법이 있다 정도로 알아두면 될 것 같습니다.
트랜잭션 프로세서
트랜잭션은 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두 수행되어야 할 일련의 연산들을 의미한다.
트랜잭션은 데이터베이스 시스템에서 병행 제어 트랜잭션 프로세서 및 회복 작업 시 처리되는 작업의 논리적 단위로 사용
트랜잭션은 사용자가 시스템에 대한 서비스 요구 시 시스템이 응답하기 위한 상태 변환 과정의 작업 단위로 사용
트랜잭션 특성
다음은 데이터의 무결성을 보장하기 위하여 DBMS의 트랜젝션이 가져야 할 특성이다.
Atomicity(원자성)
트랜잭션의 연산은 데이터베이스에 모두 반영되도록 완료(Commit)되든지 아니면 전혀 반영되지 않도록 복구(Rollback)되어야 함
트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 함
Consistency(일관성)
트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환
시스템이 가지고 있는 고정 요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 함
Isolation(독립성, 격리성, 순차성)
둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행 중에 다른 트랜잭션의 연산이 끼어들 수 없음
수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없음
Durability(영속성, 지속성)트랜잭션 프로세서
성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 함
CRUD 분석
CRUD는 '생성(Create), 읽기(Read), 갱신(Update), 삭제(Delete)'의 앞 글자만 모아 만든 용어이며, CRUD 분석은 데이터베이스 테이블에 변화를 주는 트랜잭션의 CRUD 연산에 대해 CRUD 매트릭스를 작성하여 분석하는 것이다.
CRUD 분석으로 테이블에 발생되는 트랜잭션의 주기별 발생 횟수를 파악하고 연관된 테이블들을 분석하면 테이블에 저장되는 데이터의 양을 유추할 수 있음
CRUD 분석을 통해 많은 트랜잭션이 몰리는 테이블을 파악할 수 있으므로 디스크 구성 시 유용한 자료로 활용할 수 있음
CRUD 분석을 통해 외부 프로세스 트랜잭션의 부하가 집중되는 데이터베이스 채널을 파악하고 분산시킴으로써 연결 지연이나 타임아웃 오류를 방지할 수 있음
CRUD 매트릭스
CRUD 매트릭스는 2차원 형태의 표로서, 행에는 프로세스를, 열에는 테이블을, 행과 열이 만나는 위치에는 프로세스가 테이블에 발생시키는 변화를 표시하는 업무 프로세스와 데이터 간 상관 분석표이다.
CRUD 매트릭스를 통해 프로세스의 트랜잭션이 테이블에 수행하는 작업을 검증
CRUD 매트릭스의 각 셀에는 Create, Read, Update, Delete의 앞 글자가 들어가며, 복수의 변화를 줄 때는 기본적으로 C > D > U > R 의 우선순위를 적용하여 한가지만 적지만, 활용 목적에 따라 모두 기록할 수 있음
CRUD 매트릭스가 완성되었다면 C, R, U, D 중 어느 것도 적히지 않은 행이나 열, C나 R이 없는 행을 확인하여 불필요하거나 누락된 테이블 또는 프로세스를 찾음
트랜잭션 분석
트랜잭션 분석의 목적은 CRUD 매트릭스를 기반으로 테이블에 발생하는 트랜잭션 양을 분석하여 테이블에 저장되는 데이터의 양을 유추하고 이를 근거로 DB 용량을 산정하고 DB 구조를 최적화하는 것이다.
트랜잭션 분석은 업무 개발 담당자가 수행
트랜잭션 분석을 통해 프로세스가 과도하게 접근하는 테이블을 확인하여 여러 디스크에 배치함으로써 디스크 입출력 분산을 통한 성능 향상을 가져올 수 있음
트랜잭션 분석서
트랜잭션 분석서는 단위 프로세스와 CRUD 매트릭스를 이용하여 작성하며, 구성 요소에는 단위 프로세스, CRUD 연산, 테이블명, 컬럼명, 등이 있다.
단위 프로세스 : 업무를 발생시키는 가장 작은 단위의 프로세스
CRUD 연산 : 프로세스의 트랜잭션이나 데이터베이스 테이블에 영향을 주는 C, R, U, D의 4가지 연산
테이블명, 컬럼명 : 프로세스가 접근하는 데이터베이스의 테이블명을 기록. 필요한 경우 테이블의 컬럼명을 적음. 컬럼명을 적을 때는 마침표로 연결하여 '테이블.컬럼명'과 같이 적음
트랜잭션 메시지 수명 주기
트랜잭션 메시지를 게시, 일시 중지, 게시 취소 및 삭제하는 단계는 아래에 자세히 설명되어 있습니다.
을 사용하는 사용자만 관리 역할은 트랜잭션 메시지에 액세스하고 게시할 수 있습니다.
트랜잭션 메시지 게시 프로세스
아래 차트는 전반적인 트랜잭션 메시지 게시 프로세스를 보여줍니다.
관련 항목:
트랜잭션 메시지 게시
트랜잭션 메시지를 편집하고 테스트하면 게시할 수 있습니다. 을(를) 클릭하여 Publish 버튼을 클릭합니다.
이제 "장바구니 포기" 이벤트가 트리거되는 경우, 수신자의 제목과 성, 장바구니 URL, 제품 목록이 정의되어 있다면 마지막으로 상담한 제품 또는 제품 목록, 그리고 보낼 총 장바구니 금액이 포함된 메시지를 자동으로 표시합니다.
트랜잭션 메시지에 대한 보고서에 액세스하려면 Reports 버튼을 사용하십시오. 자세한 내용은 동적 보고서.
관련 항목:
트랜잭션 메시지 게시 일시 트랜잭션 프로세서 중단
예를 들어 메시지에 포함된 데이터를 수정하기 위해 Pause 버튼을 사용하여 트랜잭션 메시지 게시를 일시 중단할 수 있습니다. 그러면 이벤트는 더 이상 처리되지 않고 대신 Adobe Campaign 데이터베이스의 큐에 보관됩니다.
큐 이벤트는 REST API에 정의된 기간 동안 보관됩니다(참조) REST API 설명서) 또는 트리거 핵심 서비스를 사용하는 경우 트리거 이벤트( Adobe Experience Cloud Triggers 정보).
Resume을(를) 클릭하면 큐에 있는 모든 이벤트(만료되지 않은 경우)가 처리됩니다. 템플릿 게시가 일시 중단된 동안 수행된 모든 수정 사항이 포함되어 있습니다.
트랜잭션 메시지 게시 취소
Unpublish을(를) 클릭하면 트랜잭션 메시지 게시를 취소할 수 있고 이전에 만든 이벤트에 해당하는 리소스를 REST API에서 삭제하는 해당 이벤트의 게시도 취소할 수 있습니다.
이제 웹 사이트를 통해 이벤트가 트리거되더라도 해당 메시지는 더 이상 전송되지 않고 데이터베이스에 저장되지 않습니다.
메시지를 다시 게시하려면 해당 이벤트 구성으로 돌아가야 합니다. 이벤트 게시, 그런 다음 메시지 게시.
일시 중지된 트랜잭션 메시지의 게시를 취소하는 경우 다시 게시하기 전에 최대 24시간까지 기다려야 할 수 있습니다. Database cleanup 워크플로우가 대기열로 전송된 모든 이벤트를 지우기 위해서 입니다.
메시지 일시 중지 단계는 트랜잭션 메시지 게시 일시 중단 섹션에 자세히 설명되어 있습니다.
매일 오전 4시에 실행되는 Database cleanup 워크플로우는 Administration > Application settings > Workflows을(를) 통해 액세스할 수 있습니다.
트랜잭션 메시지 삭제
트랜잭션 메시지 게시가 취소되었거나 트랜잭션 메시지가 아직 게시되지 않았으면 트랜잭션 메시지 목록에서 삭제할 수 있습니다. 삭제 방법:
- 을(를) 클릭합니다. Adobe 왼쪽 상단 모서리에서 로고를 선택한 다음 Marketing plans >Transactional messages >Transactional messages.
- 마우스를 원하는 메시지 위로 가져갑니다.
- Delete element 버튼을 클릭합니다.
하지만 트랜잭션 메시지를 삭제하는 것은 특정 조건에서만 수행할 수 있습니다.
트랜잭션 메시지에 Draft 상태가 있는지 확인해야 합니다. 없다면 메시지를 삭제할 수 없습니다. Draft 상태는 아직 게시되지 않았거나 게시 취소(일시 중지가 아님)된 메시지에적용됩니다.
트랜잭션 메시지: 다른 트랜잭션 메시지가 해당 이벤트에 연결되어 있지 않는 한, 트랜잭션 메시지의 게시를 취소하는 경우, 트랜잭션 메시지를 성공적으로 삭제하려면 이벤트 구성도 게시 취소해야 합니다. 자세한 내용은 이벤트 게시 취소를 참조하십시오.
이미 알림을 보낸 트랜잭션 메시지를 삭제하면 전송 및 추적 로그도 삭제됩니다.
기본 제공 이벤트 템플릿의 트랜잭션 메시지(내부 트랜잭션 메시지): 내부 트랜잭션 메시지가 해당 내부 이벤트와 연결된 유일한 메시지인 경우 삭제할 수 없습니다. 먼저 복제하거나 Resources > Templates > Transactional message templates 메뉴를 통해 다른 트랜잭션 메시지를 만들어야 합니다.
트랜젝션 잠금 오류 및 교착상태(DEADLOCK) 해결 방법
한 작업에서 잠근 리소스를 트랜잭션 프로세서 다른 작업에서 잠그려고 하여 둘 이상의 태스크가 서로 영구적으로 차단하면 교착 상태가 발생합니다. 예를 들면 다음과 같습니다.
트랜잭션 A가 1행에 대한 공유 잠금을 획득합니다.
트랜잭션 B가 2행에 대한 공유 잠금을 획득합니다.
트랜잭션 A가 2행에 대한 배타적 잠금을 요청하고 트랜잭션 B가 2행에 대해 소유하고 있는 공유 잠금을 종료 및 해제할 때까지 트랜잭션 A가 차단됩니다.
트랜잭션 B가 1행에 대한 배타적 잠금을 요청하고 트랜잭션 A가 1행에 대해 소유하고 있는 공유 잠금을 종료 및 해제할 때까지 트랜잭션 B가 차단됩니다.
트랜잭션 B가 완료되어야 트랜잭션 A도 완료될 수 있지만 트랜잭션 B는 트랜잭션 A에 의해 차단된 상태입니다. 이러한 상태를 순환 종속 관계라고 합니다. 트랜잭션 A는 트랜잭션 B에 종속되고 트랜잭션 B는 트랜잭션 A에 종속된 형태로 순환됩니다.
교착 상태의 트랜잭션은 둘 다 외부 프로세스에서 교착 상태를 해제할 때까지 기다립니다. MicrosoftSQL Server 데이터베이스 엔진 교착 상태 모니터는 교착 상태에 있는 태스크가 있는지 주기적으로 검사합니다. 순환 종속 트랜잭션 프로세서 관계가 발견되면 모니터는 두 작업 중 처리하지 않을 태스크를 하나 선택하고 해당 트랜잭션을 오류와 함께 종료합니다. 이렇게 하여 다른 태스크가 해당 트랜잭션을 완료할 수 있습니다. 오류와 함께 종료된 트랜잭션의 응용 프로그램은 해당 트랜잭션을 다시 시도하며 이 트랜잭션은 대개 교착 상태의 다른 트랜잭션이 완료된 후에 끝납니다.
응용 프로그램에 특정 코딩 규칙을 사용하여 응용 프로그램에서 교착 상태를 일으킬 가능성을 줄일 수 있습니다. 자세한 내용은 교착 상태 최소화를 참조하십시오.
교착 상태는 종종 일반적인 차단과 혼동됩니다. 트랜잭션이 다른 트랜잭션에서 잠근 리소스에 대한 잠금을 요청하면 잠금이 해제될 때까지 잠금을 요청한 트랜잭션이 기다립니다. 기본적으로 LOCK_TIMEOUT이 설정되지 않은 한 SQL Server 트랜잭션 시간은 제한되지 않습니다. 잠금을 요청하는 트랜잭션은 잠금을 소유하는 트랜잭션을 차단하기 위한 작업을 수행하지 않으므로 교착 상태에 빠지지 않고 차단됩니다. 결국 잠금을 소유하는 트랜잭션이 완료되고 잠금을 해제하면 잠금을 요청하는 트랜잭션에 잠금이 허가되고 트랜잭션이 진행됩니다.
교착 상태는 deadly embrace(치명적인 포옹)라고도 합니다.
교착 상태는 관계형 데이터베이스 관리 시스템뿐만 아니라 다중 스레드를 사용하는 어느 시스템에서나 발생할 수 있으며 데이터베이스 개체에 대한 잠금 이외의 리소스에 대해 발생할 수 있습니다. 예를 들어 다중 스레드 운영 체제의 스레드는 메모리 블록과 같은 하나 이상의 리소스를 획득할 수 있습니다. 획득하려는 리소스를 현재 다른 스레드가 소유하고 있으면 대상 리소스가 해제될 때까지 첫 번째 스레드가 기다려야 할 수 있습니다. 이렇게 대기 중인 스레드는 해당 리소스에 대해 리소스를 소유하는 스레드에 종속됩니다. 데이터베이스 엔진의 인스턴스에서 세션은 메모리나 스레드 등의 데이터베이스가 아닌 리소스를 획득할 때 교착 상태에 빠질 수 있습니다.
이 그림에서 트랜잭션 T1은 Part 테이블 잠금 리소스에 대해 트랜잭션 T2에 종속됩니다. 마찬가지로 스레드 T2는 Supplier 테이블 잠금 리소스에 대해 트랜잭션 T1에 종속됩니다. 이러한 종속 관계는 순환적이므로 스레드 T1과 T2 간에 교착 상태가 발생합니다.
테이블이 분할되고 ALTER TABLE의 LOCK_ESCALATION 설정이 AUTO로 설정된 경우에도 교착 상태가 발생할 수 있습니다. LOCK_ESCALATION이 AUTO로 설정되면 데이터베이스 엔진에서 TABLE 수준이 아니라 HoBT 수준에서 테이블 파티션을 잠그도록 허용하여 동시성이 증가합니다. 그러나 개별 트랜잭션이 테이블에 파티션 잠금을 보유하고 다른 트랜잭션 파티션에서 잠금을 원하면 교착 상태가 발생합니다. 이런 유형의 교착 상태는 LOCK_ESCALATION을 TABLE로 설정하면 방지할 수 있습니다. 하지만 이 설정으로 인해 테이블 잠금을 기다리도록 파티션에 대규모 업데이트가 강제 적용되어 동시성이 감소됩니다.
위 내용은 MSDN에서 참조한 내용이다.
하나의 테이블에 여러 트랜잭선에서 동시다발적으로 UPDATE/DELETE 등을 실행할 경우 교착상태( DEADLOCK)이 발생한다.
보통 이런경우 아래와 같은 에러메세지가 출력한다.
SqlException:System.Data.SqlClient.SqlException (0x80131904): 트랜잭션(프로세스 ID 95)이 잠금 리소스에서 다른 프로세스와의 교착 상태가 발생하여 실행이 중지되었습니다. 트랜잭션을 다시 실행하십시오.
이런 증상을 최소화 하기 위해서는 몇가지 방법이 있다.
1. 인덱스를 설정한다. 인덱스가 없는 경우 DEADLOCK 이 발생할 확률이 넓어진다.
2. 트랜젝션을 가급적 짧고 단순하게 만든다.
3. Transaction Isolation Level 을 "Read UnCommitted"로 설정한다.
4. LOCK_ESCALATION 을 "Disable", ALLOW_PAGE_LOCKS 를 "OFF"로 설정한다.
위의 4가지 항목들을 모두 설정해야 오류가 발생하지 않는것 같다.
▷ Isolation Level 설정 방법
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
쿼리문 상단에 위 설정구분을 넣어두면 된다.
▷ LOCK_ESCALATION 설정 방법
ALTER TABLE dbo.tb_ExTable SET ( LOCK_ESCALATION = DISABLE )
LOCK_ESCALATION 은 AUTO, TABLE, DISABLE 로 설정할 수 있다.(기본값 TABLE)
설정된 LOCK_ESCALATION 값을 보고 싶은경우 아래와 같은 쿼리를 실행하면 된다.
SELECT lock_escalation , lock_escalation_desc FROM sys.tables WHERE name IN ( 'tb_ExTable' )
▷ ALLOW_PAGE_LOCKS 설정 방법
EXEC SP_INDEXOPTION tb_ExTable , DISALLOWPAGELOCKS , 1;
ALLOW_PAGE_LOCKS 는 테이블 생성할 때 WITH 문에 "ALLOW_PAGE_LOCKS = OFF"를 추가 하거나
위와 같이 테이블 생성 이후 DISALLOWPAGELOCKS 를 "1"로 설정하여 값을 변경할 수 있다.
설정된 ALLOW_PAGE_LOCKS 값을 보고 싶은 경우 아래와 같은 쿼리를 실행하면 된다.
SELECT ALLOW_PAGE_LOCKS FROM sys.indexes
WHERE OBJECT_ID IN ( OBJECT_ID ( 'tb_ExTable' ))
위 항목들을 모두 설정하였는데도 에러가 발생한다면;;;;
다른 방법을 찾아보기 바란다.
SP 또는 해당 Update/Delete 작업을 최소한으로 수정하여 처리하는 방법밖에 없을것 같다.
SQL Server 2008의 OLTP(온라인 트랜잭션 프로세싱)
데이터베이스는 전반적인 수용도와 사용량 측면에서 지난 20년간 폭발적인 증가세를 보여 왔습니다. 또한 트랜잭션 프로세서 저장소 및 기술 비용의 하락은 대용량 저장소 및 데이터베이스의 확대라는 결과를 불러 왔습니다. 이와 같이 쉽게 이용할 수 있는 기술이 널리 파급되고 수많은 임베디드 데이터베이스 제품이 등장함에 따라 더 많은 데이터를 더 오래 저장할 수 있게 되어 기업은 서버 통합의 필요성을 강하게 느끼고 있는 실정 트랜잭션 프로세서 입니다.
SQL Server 2008은 오늘날의 OLTP 데이터베이스가 요구하는 바를 충족하기 위해 다음과 같은 4가지 주요 영역에 중점을 두고 있습니다.
● 확장성 및 성능. SQL Server 2008은 기업이 오늘날의 응용 프로그램이 요구하는 성능 및 확장성을 이용하여 데이터베이스 솔루션을 구축할 수 있도록 해줍니다.
● 고가용성. SQL Server 2008은 항상 사용 가능한 데이터베이스 응용 프로그램을 제공하는 동시에 관리 및 성능 측면에서 고가용성 솔루션의 오버헤드를 최소화해줍니다.● 보안성. SQL Server 2008은 귀중한 데이터를 암호화하고, 데이터 및 메타데이터의 변경된 부분을 감사하고, 외부 암호화 키를 통합 하고, 백업 파일의 데이터를 암호화 및 승인하는 방식으로 보안성이 향상된 데이터 플랫폼을 제공합니다.
● 관리 효율성. SQL Server 2008은 혁신적이고 자동화된 정책 기반의 관리 기능과 더불어 성능 모니터링, 문제 해결 및 튜닝을 위한 개선된 도구를 제공함으로써 기업이 데이터 인프라 관리에 들이는 시간과 비용을 줄일 수 있는 길을 제시합니다.
데이터 센터 및 서버 통합이 지향하는 최근의 추세, 그리고 원격 및 임베디드 데이터베이스의 증식으로 인해 데이터베이스 서버의 확장성 및 다양한 응용 프로그램을 지원하기 위한 성능이 더욱 더 중요한 요소로 대두되고 있습니다. SQL Server 2008은 데이터 수요에 맞추어 확장이 가능한 다양한 데이터베이스 환경을 제공합니다.
디스크 저장소의 가격은 대체로 저렴한 편이나, 데이터베이스 저장소 용량을 축소하면 여러 가지 이득을 얻을 수 있습니다. 데이터 파일의 크기가 크면 읽기 및 쓰기 성능이 저하될 수 있습니다. SQL Server 2008은 이러한 문제를 해결하기 위한 일환으로 데이터 압축 방식을사용합니다. 데이터를 압축하면 데이터를 보다 효과적으로 저장하고, 데이터 저장소 요구량을 축소하고, 대량의 디스크 입출력(I/O)이 수반되는 고부하 작업의 성능을 크게 개선할 수 있습니다. 또한 SQL Server 2008은 별도의 조정 없이 바로 사용할 수 있는 백업 압축을 기본 지원합니다.
그 외에도, XML, VARCHAR(MAX) 및 VARBINARY(MAX), 그리고 VARDECIMAL과 같은 데이터 형식을 지원하므로 디스크 공간의 효율적인 사용을 도모합니다. VARDECIMAL 데이터 형식을 사용하면 소수 표현식 앞뒤의 0이 제거되므로 이러한 형식의 데이터를 저장하는데 필요한 디스크 공간의 크기를 줄일 수 있습니다. 그 외에도, SQL Server 2008이 제공하는 스파스 열의 지원으로 Null 값을 위한 공간을 확보하여 초래될 수 있는 비효율적인 디스크 저장 및 성능 저하의 문제를 해결해줍니다.
데이터베이스의 규모와 기능이 계속 트랜잭션 프로세서 확대됨에 따라 서버에 설치된 메모리를 완전히 활용할 수 있는 능력이 데이터베이스 서버의 필수적 요구 사항으로 대두되고 있습니다. SQL Server 2008은 AWE 매핑 메모리의 동적 할당을 지원하므로 Windows Server 2003 Datacenter Edition을 실행하면 최대 64GB의 메모리를 수용할 수 있습니다. 이러한 특성을 활용하면 사용자의 성능 요구 사항이 트랜잭션 프로세서 충족될 수 있도록 데이터베이스를 효과적으로 확장할 수 있습니다.
SQL Server가 메모리 리소스를 동적으로 관리하지만, 데이터 시스템이 확대되고 서버가 통합됨에 따라 SQL Server 인스턴스의 상이한 작업간 성능의 균형을 유지할 수 있어야 합니다. 리소스 관리자는 SQL Server 인스턴스에서 실행되는 개개 작업별로 제한을 정의하고 우선 순위를 지정하는 기능을 제공하는 SQL Server 2008의 새로운 도구입니다. 이 기능을 이용하면 서버 통합의 장점을 활용하는 동시에 일관된 성능을 유지할 수 있습니다.
대형 데이터 저장소를 사용할 경우, 행 수준에서 잠그면 너무 많은 리소스가 소비되고 성능이 저하될 수 있습니다. SQL Server 2008은 이러한 문제의 해결을 위해 잠금 에스컬레이션에 대한 더욱 강력한 제어 기능을 통해 잠금을 파티션 또는 테이블 수준으로 에스컬레이션 할 수 있는 수단을 제공하므로 대형 데이터 저장소의 성능을 더욱 높여 줍니다. 또한 SQL Server 2008은 파티션 기반의 잠금 기능을 제공함 으로써 분할된 대형 테이블의 성능을 높일 수 있습니다. 이 기능은 대형 테이블의 동시성을 개선하면서도 대형 데이터 블록을 잠궈 성능을 최적화합니다.
데이터 환경이 확대됨에 따라 상시적인 데이터 운영의 중요성이 더욱 크게 부각되고 있습니다. SQL Server 2005는 데이터베이스 미러링과 더불어 더욱 강력한 백업 및 복원 기능을 제공함으로써 항상 사용 가능한 기술의 새 지평을 개척한 제품입니다. SQL Server 2008은 그러한 토대를 바탕으로 기간 업무에 사용되는 중요 응용 프로그램을 더욱 강력히 지원합니다.
데이터베이스 미러링을 통한 데이터베이스 가용성 증진
Microsoft는 SQL Server 2005에서 데이터베이스 미러링을 도입하여 데이터 보호 기능을 강화하고 데이터베이스의 가용성을 증진할 수 있는 길을 제시하였습니다. 데이터베이스 미러링은 데이터베이스 미러링 세션을 위한 파트너 역할을 하는 2대의 서버로 구성됩니다. 이러한 파트너 중 하나는 주 서버의 역할을 수행하고, 데이터베이스의 읽기 전용 사본이 저장된 다른 하나는 미러 서버의 역할을 수행합 니다. 데이터베이스 미러링은 기본적으로 소프트웨어 기반의 이중화 솔루션입니다.
데이터베이스 미러링은 주 서버에 장애가 발생하면 수동 또는 자동으로 장애 조치를 수행하여 데이터베이스에 대한 액세스를 보호합니다. 데이터에 대한 추가 액세스를 제공하려면 미러 사본에 대한 읽기 전용 액세스가 가능한 데이터베이스 스냅샷을 사용해 미러 서버를 구성 하면 됩니다.
데이터 페이지는 디스크가 고장나거나 전원이 차단될 경우 손상될 수 있습니다. SQL Server 2008 Enterprise Edition은 데이터의 무결성을 보호하고 파트너 노드를 활성화함으로써 이러한 잘못된 페이지 오류로부터의 복구를 자동으로 시도합니다. 이와 같이 복구가 시도되므로 SQL Server는 물리적 데이터 손상을 보다 신속히 복구할 수 있으며, 경우에 따라 사용자 개입을 요하지 않을 수도 있습니다.
데이터베이스 미러링에는 미러링 파트너간의 로그 정보 전송이 필요합니다. 대량의 데이터 전송은 미러링 서버 사이에서 지연을 초래할 수 있을 뿐 아니라 추가적인 네트워크 트래픽을 일으켜 모든 사용자와 다른 서버에까지 영향을 미칠 수 있습니다. SQL Server 2008은 이러한 데이터의 전송을 최적화하기 위해 아웃바운드 미러링 로그 스트림 압축 기술을 사용합니다. 이러한 압축 기능은 데이터베이스 미러링을 지원하기 위해 필요한 네트워크 대역폭을 최소화합니다.
대다수 환경에서 데이터베이스 미러링을 사용하기 위해 클라이언트 응용 프로그램을 변경한다는 것은 타당성을 찾기 힘든 일입니다. SQL Server 2008은 데이터베이스 미러링으로 인해 클라이언트 응용 프로그램을 변경할 필요성이 완화되도록 투명한 클라이언트 리디렉션 기능을 더불어 제공합니다. 이러한 기능을 사용하면 더 많은 기업이 데이터베이스 미러링을 활용할 수 있습니다.
많은 조직이 개별 데이터베이스가 아닌 전체 SQL Server 인스턴스를 보호할 수 있는 고가용성 솔루션을 필요로 합니다. 이러한 요구 사항을 충족하려면 SQL Server 2008을 Microsoft Cluster Service Cluster 그룹의 일부로 포함시키면 됩니다. 장애 조치 클러스터는 클라이언트의 입장에서 SQL Server 2008의 단일 인스턴스로 보이지만, 활성 서버를 사용할 수 없게 되면 다른 서버를 이용하는 식으로 장애 조치를 실현 합니다.
이전 버전의 트랜잭션 프로세서 SQL Server는 몇 가지의 제한 사항을 안고 있었던 관계로 클러스터링 솔루션의 장점이 제한될 수밖에 없었습니다. 그러한 제한 요소 중에는 클러스터링 솔루션이 SQL Server의 각 인스턴스마다 하나의 드라이브 문자를 사용해야 한다는 점과 클러스터의 모든 노드가 동일한 서브넷에 존재해야 한다는 점이 있었습니다. Windows Server 2008("Longhorn")에 트랜잭션 프로세서 SQL Server 2008을 설치하여 클러스터링하면 보다 유연한 클러스터링 구성이 제공되므로 이러한 제한 사항이 없어집니다.
그 외에도 SQL Server 2008은 업무상 중요한 응용 프로그램과 대규모 환경을 지원하기 위해 Windows Server 2008("Longhorn") 클러스 터링의 향상된 기능을 활용하여 최대 16개 노드의 클러스터를 지원합니다.
클러스터 검사 도구는 클러스터 솔루션을 위한 윈도우 카탈로그에 등록된 전체 시스템 솔루션 목록에 의존하지 않고도 하드웨어 구성의 유효성을 테스트할 수 있도록 해줍니다. 이 도구는 클러스터 솔루션을 위한 하드웨어를 선택할 때 더 큰 유연성을 발휘합니다.
복제를 이용한 데이터 액세스 유연성 증진
복제를 이용하면 사이트의 자치성 제고를 위한 원격지 데이터베이스 사본, 보고를 위한 데이터베이스의 읽기 전용 사본 또는 P2P 복제 토폴리지의 데이터베이스를 새로 추가할 수 있으며, 각 장소와 관련된 변경 사항이 해당 장소에서 적용된 후 곧 다른 장소로 복제됩니다. SQL Server 2008은 분산 응용 프로그램을 위해 트랜잭션, 병합 및 스냅숏 복제를 지원합니다.
복제는 일반적으로 상당한 구성 및 관리 작업을 필요로 하던 영역이었습니다. SQL Server 2008은 복제를 구현하고 구성하기 위한 수많은 마법사와 도구를 제공합니다.
P2P 토폴리지 마법사 및 토폴로지 뷰어는 데이터베이스 관리자에게 P2P 트랜잭션 복제를 보다 간편하게 설정하고 구성할 수 있는 수단을 제공합니다. 토폴로지 뷰어를 사용하면 기존 토폴리지를 볼 수 있으며, 그림 1과 같이 새로운 시각적 디자이너와 마법사를 사용하면 복제 토폴로지를 보다 쉽게 생성하고 수정할 수 있습니다.
그 외에도, 이전 버전의 SQL Server는 P2P 복제 토폴리지에서 하나 이상의 피어에 신규 노드를 추가하는 동안 복제 시스템의 데이터 변경을 중단해야만 했습니다. 시스템 중단은 업무에 중요한 데이터베이스에서는 적절한 방법이 아닐 수 있습니다. SQL Server 2008을 이용하면 시스템을 멈추지 않고도 복제 토폴로지에 신규 노드를 추가할 수 있기 때문에 노드를 설치하는 동안에도 업무상 중요한 대용량 데이터베이스가 계속 작동할 수 있습니다.
메모리 및 프로세서 추가시 서버 종료 문제 해소
중요한 데이터를 저장할 때 서버가 종료된다면 비즈니스 생산성에 지장이 초래될 것입니다. SQL Server 2008 Enterprise Edition은 SQL Server 서비스가 실행되는 동안에도 SQL Server에 메모리 및 프로세서를 추가할 수 있으므로 유지 관리를 위해 서버를 종료할 필요가 없습니다.
저장되는 개인 데이터의 양적 증가, 보안 문제에 대한 공공의 인식, 데이터 저장소에 대한 업계 및 정부의 규제는 안전한 데이터 솔루션의 구현이 오늘날의 조직에게 있어 중요한 문제임을 시사합니다. SQL Server에는 사용자의 보안 요구 사항에 최적화된 보안 구성을 돕는 도구가 포함되어 있습니다. SQL Server 2008은 SQL 2005의 보안성을 바탕으로 구축되었으며, 안전하면서도 사용자 지정이 가능한 보안 아키텍처, 완전한 이벤트 처리, 투명한 데이터 암호화를 지원하는 유연하고 안전한 저장소, 단순하면서도 통합된 전사적 암호화 및 키 관리 기능을 제공합니다.
안전하고 사용자 지정이 가능한 보안 아키텍처
강력한 권한 계층 구조는 관리자가 세밀한 수준에서 권한을 지정할 수 있게 하므로 필요한 사용자만이 액세스 권한을 갖도록 제한합니다. 사용자에게 데이터에 대한 액세스를 제공하기 위해 사용되는 표준 권한 이외에도, SQL Server는 보조 관리자가 할당된 작업만을 수행할 수 있도록 필요한 특정 권한을 지정하는 기능을 관리자에게 부여함으로써 관리의 유연성을 높입니다.
또한 SQL Server 2008은 Brute Force Attack을 막아 데이터에 대한 보호 수준을 높일 수 있는 암호 복잡성 및 만료 정책을 제공하며, 클라이언트 응용 프로그램과 서버간 민감한 통신의 완전한 암호화를 지원합니다.
보안에 대한 우려 및 정부의 규제가 날로 심해짐에 따라 감사는 많은 데이터베이스 환경의 핵심적인 요소로 자리잡게 되었습니다. 감사 로그는 데이터베이스 서버에서 발생하는 모든 이벤트를 기록할 수 있어야 할 뿐 아니라 필요한 이벤트에 대한 감사만을 구성할 수 있을 정도로 유연해야 합니다. SQL Server 2008을 이용하면 서버 및 데이터베이스 계층 등 상이한 계층에서 감사를 실행할 수 있습니다. 이러한 감사 이벤트는 "어느 데이터가 수정되었고 누가 수정을 하였는가", "얼마나 많은 로그인 시도 실패가 발생하였는가"와 같은 질문에 대한 답을 제시합니다. 데이터베이스 플랫폼의 상이한 계층에서 감사를 구성할 수 있는 유연성에 더하여, 사내의 한 SQL Server에서 다른 SQL Server로 트랜잭션 프로세서 감사 설정 정보를 배포할 수 있으므로 전사적 감사 솔루션의 배포 및 관리가 전에 비해 더욱 쉬워졌습니다.
감사 정보가 전사적으로 배포되는 동안 감사 데이터 수집기는 감사 보고서를 통합하여 전사적 추세에 대한 다양한 분석 정보를 제공합니다.
투명한 데이터 암호화를 통한 저장소의 유연성 및 안전성 확보
SQL 2005의 경우, 키 기반의 암호화 기능이 지원되기는 하나 암호화된 열을 인덱싱하거나 검색할 수는 없습니다. 아울러 암호화된 데이터에 액세스하려면 클라이언트 응용 프로그램을 수정해야 합니다. SQL Server 2008은 투명한 데이터 암호화(TDE) 기능을 제공합니다. 이 기능은 데이터베이스 계층에서 구현되며 클라이언트 응용 프로그램을 수정할 필요 없이 전체 데이터베이스, 데이터 파일 또는 로그 파일의 암호 화가 가능합니다. 데이터를 디스크에 쓸 때 암호화되고 디스크에서 읽을 때 해독됩니다. 이런 식으로 구현하면 암호화된 데이터에 대한 전체 텍스트 검색을 포함하여 암호화된 데이터에 대해 인덱스를 생성하고 콘텐츠를 검색하는 일이 가능해지므로 더 많은 회사가 데이터 암호화를 활용할 수 있습니다.
전사적 암호화와 키 관리의 간소화 및 통합
SQL Server 2005의 경우, 암호화 키가 데이터와 함께 저장되며 전적으로 SQL Server 내부에서 관리됩니다. 이러한 네이티브 SQL 키 관리 기능 이외에도 SQL Server 2008은 타사 암호화 공급자, 타사 키 관리 소프트웨어 및 HSM(하드웨어 보안 모듈)을 지원합니다. 따라서 조직 내의 전체 응용 프로그램 및 서비스를 대상으로 암호화와 키 관리를 단순화하고 통합할 수 있습니다.
제품의 기능이 확대되고 서버 통합을 향한 움직임이 가속화되고 원격 데이터베이스가 늘어남에 따라 데이터 관리의 복잡성이 가중되고 있습니다.
SQL Server 및 데이터베이스에 대한 정책 기반 관리
데이터베이스 및 사용자의 수가 날로 증가함에 따라 관리자는 정책을 통해 트랜잭션 프로세서 제공되는 사전 관리 역량을 갖추지 않을 수 없게 되었습니다. SQL Server 2008의 정책 기반 관리는 구성 정책을 정의하고 그러한 정책을 전사적으로 서버, 데이터베이스, 테이블 및 기타 대상에 적용 하는 기능을 제공합니다. 이러한 정책을 이용하면 시스템의 변경을 예방하거나 모니터링할 수 있습니다. 이렇게 생성된 정책은 데이터 베이스 관리자가 일상적인 유지 관리 작업에 소비하는 시간을 줄여 줍니다.
트리거를 사용하여 정책을 사전에 적용하거나, 변경이 발생한 후에 Service Broker를 사용하여 정책 응용 프로그램을 처리하거나, 또는 SQL Server 에이전트를 사용하여 정책의 적용을 예약할 수도 있습니다. 또한 임시 실행을 통해 개체를 실시간으로 정책과 대비하여 확인 할 수 있습니다.
SQL Server Management Studio를 이용한 통합 서버 관리
SQL Server Management Studio는 데이터베이스 및 데이터베이스 서버의 액세스, 관리, 구성 및 개발을 위해 사용할 수 있는 통합 환경을 비롯하여, 풍부한 스크립팅 기능과 편리한 그래픽 환경을 제공합니다. 이 응용 프로그램을 이용하면 로컬 및 원격 서버를 관리할 수 있습 니다. SQL Server Management Studio는 다양한 기술 수준의 데이터베이스 관리자를 위해 설계되었습니다.
서버 및 데이터베이스 통계 수집과 관리의 중앙화
성능 문제를 해결하려면 정확한 데이터가 있어야 할 뿐 아니라 데이터에 손쉽게 액세스할 수 있어야 합니다. SQL Server 2008은 SQL Server 인스턴스에 대한 문제 해결, 튜닝 및 모니터링이 가능하도록 설계된 성능 데이터 수집 도구를 통해 이러한 요구 사항을 충족합니다. 데이터베이스 관리자는 이러한 도구를 이용하여 성능 문제를 보다 신속히 해결하고 조정할 수 있습니다.
성능 데이터 수집 기능의 3가지 기본적인 기능 영역은 다음과 같습니다.
● SQL Trace, 시스템 모니터, DMV(동적 관리 뷰) 및 로그와 같은 여러 원본으로부터의 낮은 오버헤드 데이터 컬렉션.
● 수집된 데이터를 저장하기 위한 중앙 데이터 관리 웨어하우스. 기록 데이터와 기준 데이터를 비교하여 추세를 파악하고 미래의 성능 요구 사항 예측 가능.
● 모든 관련 문제 해결 정보를 한 곳에 모아 제공하는 동시에 개괄적인 추상 개요부터 특정 데이터까지 하향식으로 추적하여 문제의 근본 원인을 찾아 제시하는 Integrated Reporting Services 기능.
SQL Server 2008은 보안성과 신뢰성 그리고 높은 확장성을 바탕으로 업무상 중요한 응용 프로그램으로 사용되는 포괄적인 데이터 플랫 폼으로, 차세대 데이터베이스의 확대 요구 사항을 충족합니다. 또한 어떠한 데이터 형식 또는 장치에서도 사용할 수 있는 풍부한 서비스 도구 집합입니다. 개선된 리소스 활용, 향상된 잠금 기능, 그리고 최적화된 데이터 저장소는 더 나은 성능과 확장성을 제공합니다. SQL Server 2008은 Performance Studio의 개선된 성능 모니터링 및 보고 도구와 더불어 데이터 플랫폼의 관리를 단순화하는 혁신적인 정책 기반 인프라를 제공합니다. 끝으로, SQL 2008은 개선된 데이터베이스 미러링 및 장애 조치 클러스터링을 통해 높은 가용성을 제공하는 동시에 Windows Server 2008에 설치하여 얻을 수 있는 제반 기능을 활용할 수 있습니다.
Spring Batch - 청크 프로세스 이해
청크사이즈만큼 가질 수 있는 List와 예외에 대한 필드들이 있습니다.
내부 클래스로 ChunkIterator를 갖고 있는데 이는 Chunk가 갖고있는 items들을 한 건씩 트랜잭션 프로세서 트랜잭션 프로세서 가져올 때 사용합니다.
ChunkOrientedTasklet
기본 개념
- 스프링 배치에서 제공하는 Tasklet 구현체로 Chunk 지향 프로세싱을 담당하는 도메인 객체 입니다.
- ItemReader, ItemWriter, ItemProcessor를 사용해 Chunk 기반 데이터 입출력을 담당합니다.
- TaskletStep에 의해서 반복적으로 실행되며, ChunkOrientedTasklet이 실행될 때마다 매번 새로운 트랜잭션이 생성 되어 처리됩니다.
- exception이 발생할 경우, 해당 Chunk는 롤백되며 이전에 커밋한 Chunk는 완료 상태가 유지됩니다.
- 내부적으로 ItemReader를 핸들링하는 ChunkProvider와 ItemProcessor, ItemWriter를 핸들링하는 ChunkProcessor 타입의 구현체를 갖습니다.
실행 순서
- TaskletStep이 execute 메서드로 ChunkOrientedTasklet를 호출합니다.
- ChunkOrientedTasklet는 provide 메서드로 ChunkProvider를 호출합니다.
- ChunkProvider는 ItemReader에게 Item을 한 건씩 read하도록 지시합니다.
- 이 과정이 Chunk size만큼 반복됩니다.
- ChunkOrientedTasklet는 ChunkProcessor에게 읽은 데이터를 가공하라고 명령합니다.
- ChunkProcessor는 ItemProcessor에게 명령하고 ItemProcessor는 전달된 아이템 개수만큼 반복하여 가공합니다.
- ChunkProcessor는 가공된 아이템을 ItemWriter에 전달합니다.
- ItemWriter는 저장하는 등 쓰기 처리를 합니다.
- 이것이 하나의 Chunk Size 사이클로 이후 다시 ChunkOrientedTasklet에 가서 읽을 Item이 없을 때까지 반복합니다.
ChunkProvider
- ItemReader를 사용해서 소스로부터 아이템을 Chunk size만큼 읽어서 Chunk단위로 만들어 제공하는 도메인 객체
- Chunk를 만들고 내부적으로 반복문을 사용해서 ItemReader.read()를 계속 호출하면서 item을 Chunk에 쌓습니다.
- Chunk size만큼 item을 읽으면 반복문이 종료되고 ChunkProcessor로 넘깁니다.
- ItemReader가 읽은 item이 null일 경우 read 반복문이 종료되고 해당 Step의 반복문도 종료됩니다.
ChunkProcessor
- ItemProcessor를 사용해서 Item을 변형, 가공, 필터링하고 ItemWriter를 사용해서 Chunk 데이터를 저장, 출력합니다.
- Chunk를 만들고 앞에서 넘어온 Chunk의 item을 한 건씩 itemProcessor를 통해 처리한 후 Chunk에 저장합니다.
- 만약 ItemProcessor가 존재하지 않는다면 바로 Chunk에 저장합니다.
기본 API
위에 Chunk가 두 개 표기되어 있는데 실제로는 한 개만 사용 가능합니다.
두가지 방법이 있다 정도로 알아두면 될 것 같습니다.ItemReader
- 다양한 입력으로부터 데이터를 읽어서 제공하는 인터페이스 입니다.
- 플랫 파일 - csv, txt
- XML, Jsono
- Database
- Message Queuing 서비스
- Custom reader
- ItemStream은 파일 스트림 연결 종료, DB 커넥션 연결 종료 등의 장치 초기화 등의 작업에 사용됩니다.
- ExecutionContext에 read와 관련된 여러 가지 상태 정보를 저장해두고 재시작 시 참조됩니다.
- 입력 데이터를 읽고 다음 데이터로 이동합니다.
- 아이템 하나를 리턴하며 더 이상 아이템이 없는 경우 null 리턴합니다.
- 아이템 하나는 파일의 한 줄, DB의 한 row, XML 파일에서 하나의 엘리먼트를 의미합니다.
- 더 이상 처리해야 할 item이 없어도 예외가 발생하지 않고 itemProcessor와 같은 다음 단계로 넘어갑니다.
ItemWriter
- Chunk 단위로 데이터를 받아 일괄 출력 작업을 위한 인터페이스 입니다.
- 플랫 파일 - csv, txt
- XML, Jsono
- Database
- Message Queuing 서비스
- Mail Service
- Custom reader
- 출력 데이터를 아이템 리스트로 받아서 처리합니다.
- 출력이 완료되고 트랜잭션이 종료되면 새로운 Chunk 단위 프로세스로 이동합니다.
ItemProcessor
- 데이터를 출력하기 전에 데이터를 가공 및 필터링 역할을 하는 인터페이스 입니다.
- ItemReader 및 ItemWriter와 분리되어 비즈니스 로직을 구현할 수 있습니다.
- ItemReader로부터 받은 아이템을 특정 타입으로 변환해서 ItemWriter에 넘겨 줄 수 있습니다.
- Itemreader로부터 받은 아이템들 중 필터과정을 거쳐서 원하는 아이템들만 ItemWriter로 넘겨줄 수 있습니다.
- ChunkOrientedTasklet 실행 시 선택적 요소기 때문에 필수 요소는 아닙니다.
- O process()
- I 제네릭은 ItemReader에서 받을 데이터 타입
- O 제네릭은 ItemWriter에게 트랜잭션 프로세서 보낼 데이터 타입
- 아이템을 하나씩 가공 처리하며 null을 리턴할 경우 해당 아이템은 Chunk에 저장되지 않습니다.
ItemStream
- ItemReader와 ItemWriter 처리 과정 중 상태를 저장하고 오류가 발생하여 재시작 시 해당 상태를 참조하여 실패한 곳부터 재시작하도록 지원합니다.
- 리소스를 열고(open) 닫아야(close) 하며 입출력 장치 초기화 등의 작업을 해야하는 경우 사용합니다.
- 대부분의 구현체는 다 만들어져 있기 때문에 구현체를 사용한다면 직접 구현할 일은 없습니다.
- 예를 들어, 총 10개의 데이터를 Chunk 5단위로 진행한다면 총 2번의 update가 발생합니다. 만약 9번째 데이터를 읽는 과정에서 문제가 발생하면 첫번째 청크 커밋은 완료가 된 상태로 재시작 시에는 open에서 ExecutionContext에서 정보를 가져와 6번째 데이터부터 다시 시작할 수 있습니다.
최종 아키텍처
- Job을 실행하면 TaskletStep이 실행됩니다.
- Tasklet은 내부에 RepeatTemplate라는 반복기를 가지고 있어 ChunkOrientedTasklet을 반복합니다.
- ChunkOrientedTasklet이 실행될 때 스프링 배치는 Transaction 경계를 생성합니다.
- Chunk 단위로 작업을 시작합니다.
- SimpleChunkProvider도 내부적으로 RepeatTmplate 반복기를 갖고 있어 ItemReader을 Chunk size만큼 반복시켜서 데이터를 읽습니다.
- Chunk Size만큼 읽고 읽은 아이템이 담긴 Chunk를 SimpleChunkProcessor에 넘깁니다.
- SimpleChunkProcessor는 전달받은 Chunk 데이터를 한 건씩 읽어서 ItemProcessor로 데이터를 가공하여 Chunk에 저장합니다.
- ItemWriter에게 Chunk가 갖고 있는 List값을 전달하고 ItemWriter는 출력 처리를 합니다.(트랜잭션 커밋)
- 이 과정이 청크 단위로 반복되고 ItemReader에서 null 값을 읽을 때 반복 작업이 끝나게 됩니다.
만약 중간에 예외가 발생한다면 트랜잭션 롤백이 발생하고 작업이 중단됩니다.
만약 ItemReader에서 null값을 읽어오게 된다면 RepeatStatus.FINISHED를 통해 현재 작업을 마지막으로 다음부터는 반복 작업이 일어나지 않게 됩니다.
Chunk 단위마다 새로운 트랜잭션 이 생성되고 커밋되는 과정이 존재하는 것을 알아둡시다.본 포스팅은 인프런 정수원님의 ‘스프링 배치 - Spring Boot 기반으로 개발하는 Spring Batch’ 강의를 듣고 정리한 내용을 바탕으로 복습을 위해 작성하였습니다. [강의 링크]
About
안녕하세요! 몰입을 즐기는 백엔드 개발자 Backtony 입니다 👋
비전공자 시절부터 독학으로 공부한 내용을 하나씩 정리해 나가면서 기술 블로그를 운영하고 있습니다.
0 개 댓글