[펌]Database Snapshot의 데이터 변경이 가능할까요?
하지만 특정 경우에 대해서는 데이터 변경이 가능하여 이 부분에 대해서 소개드립니다.
길게 이야기할 필요 없이 바로 테스트를 진행해보도록 하겠습니다.
1. 테스트 환경 셋팅
--@@ Orig 데이터베이스 생성
IF DB_ID('Orig') IS NOT NULL
DROP DATABASE [Orig]
GO
CREATE DATABASE [Orig]
ON PRIMARY ( NAME = N'Orig', FILENAME = N'D:\Orig.mdf')
GO
USE [Orig]
GO
IF OBJECT_ID('dbo.TestTable', 'U') IS NOT NULL
DROP TABLE dbo.TestTable
GO
--@@ 사용자 테이블 생성
CREATE TABLE dbo.TestTable (Col1 int)
GO
IF OBJECT_ID('dbo.UpdView', 'V') IS NOT NULL
DROP VIEW dbo.UpdView
GO
--@@ 뷰 생성
CREATE VIEW dbo.UpdView
AS
SELECT Col1
FROM Orig.dbo.TestTable
GO
--@@ 테스트 데이터 입력
INSERT INTO dbo.TestTable (Col1) VALUES (1)
GO
IF DB_ID('Orig_Snapshot') IS NOT NULL
DROP DATABASE [Orig_Snapshot]
GO
--@@ 스냅샷 생성
CREATE DATABASE [Orig_Snapshot]
ON PRIMARY ( NAME = N'Orig', FILENAME = N'D:\Orig_Snapshot.ss') AS SNAPSHOT OF [Orig]
GO
2. 테스트 진행
--@@ 스냅샷 데이터베이스로 이동
USE [Orig_Snapshot]
GO
--@@ 현재 데이터 확인
SELECT * FROM dbo.UpdView
GO
--@@ 데이터 입력
INSERT INTO dbo.UpdView VALUES (2), (3);
GO
--@@ 데이터 변경
UPDATE dbo.UpdView SET Col1 = 99 WHERE Col1 = 3;
GO
--@@ 데이터 삭제
DELETE FROM dbo.UpdView
WHERE Col1 = 1;
GO
-- @@ 데이터 변경내용 조회
SELECT * FROM dbo.UpdView;
GO
3. 결론/의견
> View 구문 내에 데이터베이스명을 적어준 부분으로 인하여 이러한 현상이 발생하는 것입니다.
뷰를 만들 때 from 절에 데이터베이스명을 명시해주면 스냅샷 데이터베이스에서 뷰를 조회하더라도
실제 DB에서 데이터를 가지고 옵니다. (당연히도)
> 프로시져도 마찬가지로 동작할 것이기 때문에 스냅샷 데이터베이스를 사용할 경우 주의가 필요할 것 같습니다.
> 잘 사용하면 스냅샷 데이터베이스 활용성을 높일 수 있는 반면에 이해가 없이 사용할 경우 문제가 되어질 수
있으니 알아두시는 것이 좋을 듯 합니다.
출처. Successfully execute an INSERT, UPDATE and DELETE against a Database Snapshot
[펌/Tip]SQL Server 2012 (Denali) 데이터베이스 생성이 가능한 최소 용량은?
SQL Server 2008에서 잘 사용하던 쿼리가 SQL Server 2012 CTP3에서 수행을 해보니 1803 에러가 발생해서
왜 그런지 조사를 해보았다는 내용입니다.
설마 진짜 안되겠느냐라는 생각에 한번 해보았습니다. (2M 용량의 데이터베이스를 생성)
이유는 버전이 변경되어지면서 시스템 테이블이 추가되어지고, 변경되어지면서 데이터베이스 생성을 위한 기본용량이
더 커졌기 때문입니다.
상세한 내용에 대해서 궁금하신 분은 아래의 글 참고 부탁드립니다.
출처.
http://blogs.msdn.com/b/psssql/archive/2011/10/29/error-1803-and-model-size-change-in-sql-server-2012.aspx
SQL Server 2012 (Denali) 신규 기능 Columnstore Indexes 소개 (Part 2)
Columnstore 인덱스에 대해서 팀 내 소개를 드렸는데, 몇가지 질문을 받아서 관련하여 테스트해 본 내용을 정리해보았습니다.
아래에 진행된 테스트는 Part 1에서 만든 임시테이블을 기준으로 진행된 점 참고 부탁드립니다.
1. 일반 인덱스와 컬럼스토어 인덱스의 크기 비교
1-1. 인덱스 크기 비교 스크립트 (쿼리가 길어서 첨부파일로 올림)
1-2. 인덱스 크기 비교 결과
1-3. 의견
- 일반 인덱스의 경우 약 1500MB인데, 동일한 name 컬럼에 대해서 columnstore 인덱스로 구성한 경우 약 270M로 5.5배이상 축소되어짐.
- Columnstore 인덱스의 경우 압축등의 기술을 통하여 대량의 데이터 집계 및 분석에 최적화되어짐.
- 여기서 추가적인 의문이 생김. Columnstore 인덱스는 equal 검색에도 사용할 수 있을까?/적합할까?
2. equal 비교에서의 성능 비교
2-1. 일반 인덱스에서 equal 비교
-- 쿼리
select top 10 *
from ColumnstoreTable with (readuncommitted, index(idx_ColumnstoreTable_name_normal))
where name = 'ColumnstoreTable'
-- 실행계획
-- 쿼리 실행 비용
2-2. 컬럼스토어 인덱스에서 equal 비교
-- 쿼리
select top 10 *
from ColumnstoreTable with (readuncommitted, index(idx_ColumnstoreTable_name))
where name = 'ColumnstoreTable'
-- 실행계획
-- 쿼리 실행 비용
2-3. 의견
- 논리 읽기수를 비교하면 약 160배 이상 일반 인덱스가 빠른 것을 볼 수 있음. (일반인덱스 : 14 pages, 컬럼스토어인덱스 : 2255 pages)
- 컬럼스토어 인덱스의 경우 실행계획을 보면 Index scan으로 풀리는 것을 볼 수 있음.
- 컬럼스토어인덱스의 경우 대량 집계에 최적화된 구조로 index seek가 불가함.
3. 컬럼스토어 인덱스가 있는 테이블의 경우 DML이 안된다고 하는데 진짜 안될까?
3-1. Insert
-- 쿼리
insert into ColumnstoreTable
(name ,id ,xtype ,uid ,info ,status ,base_schema_ver ,replinfo ,parent_obj ,crdate ,ftcatid ,schema_ver ,stats_schema_ver ,type
,userstat ,sysstat ,indexdel ,refdate ,version ,deltrig ,instrig ,updtrig ,seltrig ,category ,cache )
select top 1
name ,id ,xtype ,uid ,info ,status ,base_schema_ver ,replinfo ,parent_obj ,crdate ,ftcatid ,schema_ver ,stats_schema_ver ,type
,userstat ,sysstat ,indexdel ,refdate ,version ,deltrig ,instrig ,updtrig ,seltrig ,category ,cache
from ColumnstoreTable
-- 결과
3-2. Delete
-- 쿼리
delete from ColumnstoreTable
-- 결과
3-3. Update
-- 쿼리
update ColumnstoreTable set name = 'hyunsoolim'
-- 결과
4. 결론/의견
- Columnstore index를 잘 활용하면 좋을 것 같습니다. 하지만 그만큼 주의를 요하는 부분도 있으니 실제 서비스에 적용하기 전에는 주의가 필요할 것 같습니다.
- 파티션테이블과 접목시키면 DML이 안되는 단점은 극복이 가능할 것 같습니다. (나중에 테스트해볼 예정임)
참고. Part 1 문서 하단 참고
