적용 대상:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Azure Synapse Analytics
분석 플랫폼 시스템(PDW)
Microsoft Fabric
의 웨어하우스Microsoft Fabric 미리 보기의 SQL 데이터베이스
열과 제약 조건을 변경, 추가 또는 삭제하여 테이블 정의를 수정합니다.
ALTER TABLE
또한 파티션을 다시 할당하고 다시 빌드하거나 제약 조건 및 트리거를 사용하지 않도록 설정하고 사용하도록 설정합니다.
디스크 기반 테이블과 메모리 최적화 테이블의 구문 ALTER TABLE
은 다릅니다. 다음 링크를 사용하여 테이블 형식의 적절한 구문 블록 및 적절한 구문 예제로 바로 이동합니다.
디스크 기반 테이블:
메모리 최적화 테이블:
구문 표기 규칙에 대한 자세한 내용은 Transact-SQL 구문 표기 규칙을 참조하세요.
디스크 기반 테이블의 구문
ALTER TABLE { database_name.schema_name.table_name | schema_name.table_name | table_name }
{
ALTER COLUMN column_name
{
[ type_schema_name. ] type_name
[ (
{
precision [ , scale ]
| max
| xml_schema_collection
}
) ]
[ COLLATE collation_name ]
[ NULL | NOT NULL ] [ SPARSE ]
| { ADD | DROP }
{ ROWGUIDCOL | PERSISTED | NOT FOR REPLICATION | SPARSE | HIDDEN }
| { ADD | DROP } MASKED [ WITH ( FUNCTION = ' mask_function ') ]
}
[ WITH ( ONLINE = ON | OFF ) ]
| [ WITH { CHECK | NOCHECK } ]
| ADD
{
<column_definition>
| <computed_column_definition>
| <table_constraint>
| <column_set_definition>
} [ ,...n ]
| [ system_start_time_column_name datetime2 GENERATED ALWAYS AS ROW START
[ HIDDEN ] [ NOT NULL ] [ CONSTRAINT constraint_name ]
DEFAULT constant_expression [WITH VALUES] ,
system_end_time_column_name datetime2 GENERATED ALWAYS AS ROW END
[ HIDDEN ] [ NOT NULL ][ CONSTRAINT constraint_name ]
DEFAULT constant_expression [WITH VALUES] ,
start_transaction_id_column_name bigint GENERATED ALWAYS AS TRANSACTION_ID START
[ HIDDEN ] NOT NULL [ CONSTRAINT constraint_name ]
DEFAULT constant_expression [WITH VALUES],
end_transaction_id_column_name bigint GENERATED ALWAYS AS TRANSACTION_ID END
[ HIDDEN ] NULL [ CONSTRAINT constraint_name ]
DEFAULT constant_expression [WITH VALUES],
start_sequence_number_column_name bigint GENERATED ALWAYS AS SEQUENCE_NUMBER START
[ HIDDEN ] NOT NULL [ CONSTRAINT constraint_name ]
DEFAULT constant_expression [WITH VALUES],
end_sequence_number_column_name bigint GENERATED ALWAYS AS SEQUENCE_NUMBER END
[ HIDDEN ] NULL [ CONSTRAINT constraint_name ]
DEFAULT constant_expression [WITH VALUES]
]
PERIOD FOR SYSTEM_TIME ( system_start_time_column_name, system_end_time_column_name )
| DROP
[ {
[ CONSTRAINT ][ IF EXISTS ]
{
constraint_name
[ WITH
( <drop_clustered_constraint_option> [ ,...n ] )
]
} [ ,...n ]
| COLUMN [ IF EXISTS ]
{
column_name
} [ ,...n ]
| PERIOD FOR SYSTEM_TIME
} [ ,...n ] ]
| [ WITH { CHECK | NOCHECK } ] { CHECK | NOCHECK } CONSTRAINT
{ ALL | constraint_name [ ,...n ] }
| { ENABLE | DISABLE } TRIGGER
{ ALL | trigger_name [ ,...n ] }
| { ENABLE | DISABLE } CHANGE_TRACKING
[ WITH ( TRACK_COLUMNS_UPDATED = { ON | OFF } ) ]
| SWITCH [ PARTITION source_partition_number_expression ]
TO target_table
[ PARTITION target_partition_number_expression ]
[ WITH ( <low_priority_lock_wait> ) ]
| SET
(
[ FILESTREAM_ON =
{ partition_scheme_name | filegroup | "default" | "NULL" } ]
| SYSTEM_VERSIONING =
{
OFF
| ON
[ ( HISTORY_TABLE = schema_name . history_table_name
[, DATA_CONSISTENCY_CHECK = { ON | OFF } ]
[, HISTORY_RETENTION_PERIOD =
{
INFINITE | number {DAY | DAYS | WEEK | WEEKS
| MONTH | MONTHS | YEAR | YEARS }
}
]
)
]
}
| DATA_DELETION =
{
OFF
| ON
[( [ FILTER_COLUMN = column_name ]
[, RETENTION_PERIOD = { INFINITE | number { DAY | DAYS | WEEK | WEEKS
| MONTH | MONTHS | YEAR | YEARS } } ]
)]
} )
| REBUILD
[ [PARTITION = ALL]
[ WITH ( <rebuild_option> [ ,...n ] ) ]
| [ PARTITION = partition_number
[ WITH ( <single_partition_rebuild_option> [ ,...n ] ) ]
]
]
| <table_option>
| <filetable_option>
| <stretch_configuration>
}
[ ; ]
-- ALTER TABLE options
<column_set_definition> ::=
column_set_name XML COLUMN_SET FOR ALL_SPARSE_COLUMNS
<drop_clustered_constraint_option> ::=
{
MAXDOP = max_degree_of_parallelism
| ONLINE = { ON | OFF }
| MOVE TO
{ partition_scheme_name ( column_name ) | filegroup | "default" }
}
<table_option> ::=
{
SET ( LOCK_ESCALATION = { AUTO | TABLE | DISABLE } )
}
<filetable_option> ::=
{
[ { ENABLE | DISABLE } FILETABLE_NAMESPACE ]
[ SET ( FILETABLE_DIRECTORY = directory_name ) ]
}
<stretch_configuration> ::=
{
SET (
REMOTE_DATA_ARCHIVE
{
= ON (<table_stretch_options>)
| = OFF_WITHOUT_DATA_RECOVERY ( MIGRATION_STATE = PAUSED )
| ( <table_stretch_options> [, ...n] )
}
)
}
<table_stretch_options> ::=
{
[ FILTER_PREDICATE = { null | table_predicate_function } , ]
MIGRATION_STATE = { OUTBOUND | INBOUND | PAUSED }
}
<single_partition_rebuild__option> ::=
{
SORT_IN_TEMPDB = { ON | OFF }
| MAXDOP = max_degree_of_parallelism
| DATA_COMPRESSION = { NONE | ROW | PAGE | COLUMNSTORE | COLUMNSTORE_ARCHIVE}
| ONLINE = { ON [( <low_priority_lock_wait> ) ] | OFF }
}
<low_priority_lock_wait>::=
{
WAIT_AT_LOW_PRIORITY ( MAX_DURATION = <time> [ MINUTES ],
ABORT_AFTER_WAIT = { NONE | SELF | BLOCKERS } )
}
자세한 내용은 다음을 참조하세요.
- ALTER TABLE column_constraint
- ALTER TABLE column_definition
- ALTER TABLE computed_column_definition
- ALTER TABLE index_option
- ALTER TABLE table_constraint
메모리 최적화 테이블의 구문
ALTER TABLE { database_name.schema_name.table_name | schema_name.table_name | table_name }
{
ALTER COLUMN column_name
{
[ type_schema_name. ] type_name
[ (
{
precision [ , scale ]
}
) ]
[ COLLATE collation_name ]
[ NULL | NOT NULL ]
}
| ALTER INDEX index_name
{
[ type_schema_name. ] type_name
REBUILD
[ [ NONCLUSTERED ] WITH ( BUCKET_COUNT = bucket_count )
]
}
| ADD
{
<column_definition>
| <computed_column_definition>
| <table_constraint>
| <table_index>
| <column_index>
} [ ,...n ]
| DROP
[ {
CONSTRAINT [ IF EXISTS ]
{
constraint_name
} [ ,...n ]
| INDEX [ IF EXISTS ]
{
index_name
} [ ,...n ]
| COLUMN [ IF EXISTS ]
{
column_name
} [ ,...n ]
| PERIOD FOR SYSTEM_TIME
} [ ,...n ] ]
| [ WITH { CHECK | NOCHECK } ] { CHECK | NOCHECK } CONSTRAINT
{ ALL | constraint_name [ ,...n ] }
| { ENABLE | DISABLE } TRIGGER
{ ALL | trigger_name [ ,...n ] }
| SWITCH [ [ PARTITION ] source_partition_number_expression ]
TO target_table
[ PARTITION target_partition_number_expression ]
[ WITH ( <low_priority_lock_wait> ) ]
}
[ ; ]
-- ALTER TABLE options
< table_constraint > ::=
[ CONSTRAINT constraint_name ]
{
{PRIMARY KEY | UNIQUE }
{
NONCLUSTERED (column [ ASC | DESC ] [ ,... n ])
| NONCLUSTERED HASH (column [ ,... n ] ) WITH ( BUCKET_COUNT = bucket_count )
}
| FOREIGN KEY
( column [ ,...n ] )
REFERENCES referenced_table_name [ ( ref_column [ ,...n ] ) ]
| CHECK ( logical_expression )
}
<column_index> ::=
INDEX index_name
{ [ NONCLUSTERED ] | [ NONCLUSTERED ] HASH WITH (BUCKET_COUNT = bucket_count) }
<table_index> ::=
INDEX index_name
{ [ NONCLUSTERED ] HASH (column [ ,... n ] ) WITH (BUCKET_COUNT = bucket_count)
| [ NONCLUSTERED ] (column [ ASC | DESC ] [ ,... n ] )
[ ON filegroup_name | default ]
| CLUSTERED COLUMNSTORE [ WITH ( COMPRESSION_DELAY = { 0 | delay [MINUTES] } ) ]
[ ON filegroup_name | default ]
}
Azure Synapse Analytics 및 병렬 데이터 웨어하우스용 구문
ALTER TABLE { database_name.schema_name.source_table_name | schema_name.source_table_name | source_table_name }
{
ALTER COLUMN column_name
{
type_name [ ( precision [ , scale ] ) ]
[ COLLATE Windows_collation_name ]
[ NULL | NOT NULL ]
}
| ADD { <column_definition> | <column_constraint> FOR column_name} [ ,...n ]
| DROP { COLUMN column_name | [CONSTRAINT] constraint_name } [ ,...n ]
| REBUILD {
[ PARTITION = ALL [ WITH ( <rebuild_option> ) ] ]
| [ PARTITION = partition_number [ WITH ( <single_partition_rebuild_option> ] ]
}
| { SPLIT | MERGE } RANGE (boundary_value)
| SWITCH [ PARTITION source_partition_number
TO target_table_name [ PARTITION target_partition_number ] [ WITH ( TRUNCATE_TARGET = ON | OFF ) ] ]
}
[ ; ]
<column_definition>::=
{
column_name
type_name [ ( precision [ , scale ] ) ]
[ <column_constraint> ]
[ COLLATE Windows_collation_name ]
[ NULL | NOT NULL ]
}
<column_constraint>::=
[ CONSTRAINT constraint_name ]
{
DEFAULT constant_expression
| PRIMARY KEY NONCLUSTERED (column_name [ ,... n ]) NOT ENFORCED -- Applies to Azure Synapse Analytics only
| UNIQUE (column_name [ ,... n ]) NOT ENFORCED -- Applies to Azure Synapse Analytics only
}
<rebuild_option > ::=
{
DATA_COMPRESSION = { COLUMNSTORE | COLUMNSTORE_ARCHIVE }
[ ON PARTITIONS ( {<partition_number> [ TO <partition_number>] } [ , ...n ] ) ]
| XML_COMPRESSION = { ON | OFF }
[ ON PARTITIONS ( {<partition_number> [ TO <partition_number>] } [ , ...n ] ) ]
}
<single_partition_rebuild_option > ::=
{
DATA_COMPRESSION = { COLUMNSTORE | COLUMNSTORE_ARCHIVE }
}
Fabric의 Warehouse 구문
ALTER TABLE { database_name.schema_name.table_name | schema_name.table_name | table_name }
{
ADD { column_name <data_type> [COLLATE collation_name] [ <column_options> ] } [ ,...n ]
| ADD { <column_constraint> FOR column_name} [ ,...n ]
| DROP { COLUMN column_name | [CONSTRAINT] constraint_name } [ ,...n ]
}
[ ; ]
<column_options> ::=
[ NULL ] -- default is NULL
<data type> ::=
datetime2 ( n )
| date
| time ( n )
| float [ ( n ) ]
| real [ ( n ) ]
| decimal [ ( precision [ , scale ] ) ]
| numeric [ ( precision [ , scale ] ) ]
| bigint
| int
| smallint
| bit
| varchar [ ( n ) ]
| char [ ( n ) ]
| varbinary [ ( n ) ]
| uniqueidentifier
<column_constraint>::=
[ CONSTRAINT constraint_name ]
{
PRIMARY KEY NONCLUSTERED (column_name [ ,... n ]) NOT ENFORCED
| UNIQUE NONCLUSTERED (column_name [ ,... n ]) NOT ENFORCED
| FOREIGN KEY
( column [ ,...n ] )
REFERENCES referenced_table_name [ ( ref_column [ ,...n ] ) ] NOT ENFORCED
}
Arguments
database_name
테이블이 생성된 데이터베이스 이름입니다.
schema_name
테이블이 속한 스키마의 이름입니다.
table_name
변경할 테이블의 이름입니다. 테이블이 현재 데이터베이스에 없거나 현재 사용자가 소유한 스키마에 포함되지 않은 경우에는 데이터베이스와 스키마를 명시적으로 지정해야 합니다.
ALTER COLUMN
명명된 열을 변경하도록 지정합니다.
수정된 열은 다음과 같을 수 없습니다.
timestamp 데이터 형식이 있는 열
테이블의 경우입니다
ROWGUIDCOL
.계산 열 또는 계산 열에 사용되는 열
문에 의해
CREATE STATISTICS
생성된 통계에 사용됩니다. 사용자는 통계를 삭제하기 위해 실행DROP STATISTICS
해야 성공합니다ALTER COLUMN
. 이 쿼리를 실행하여 사용자가 테이블에 대해 만든 모든 통계와 통계 열을 가져옵니다.SELECT s.name AS statistics_name, c.name AS column_name, sc.stats_column_id FROM sys.stats AS s INNER JOIN sys.stats_columns AS sc ON s.object_id = sc.object_id AND s.stats_id = sc.stats_id INNER JOIN sys.columns AS c ON sc.object_id = c.object_id AND c.column_id = sc.column_id WHERE s.object_id = OBJECT_ID('<table_name>');
Note
쿼리 최적화 프로그램에서 자동으로 생성되는 통계는 자동으로 삭제됩니다
ALTER COLUMN
.또는
PRIMARY KEY
[FOREIGN KEY] REFERENCES
제약 조건에 사용됩니다.또는
CHECK
UNIQUE
제약 조건에 사용됩니다. 그러나 또는UNIQUE
제약 조건에 사용되는 가변 길이 열의 길이를CHECK
변경할 수 있습니다.DEFAULT 정의와 연결되는 열. 그러나 데이터 형식이 변경되지 않은 경우 열의 길이, 전체 자릿수 또는 소수 자릿수를 변경할 수 있습니다.
text, ntextntext 및 image 열의 데이터 형식은 다음과 같은 방식으로만 변경할 수 있습니다.
- text에서 varchar(max) , nvarchar(max) 또는 xml로
- ntext에서 varchar(max) , nvarchar(max) 또는 xml로
- image에서 varbinary(max) 로
일부 데이터 형식 변경으로 인해 데이터가 변경될 수 있습니다. 예를 들어 nchar 또는 nvarchar 열을 char 또는 varchar로 변경하면 확장 문자가 변환될 수 있습니다. 자세한 내용은 CAST 및 CONVERT를 참조하세요. 열의 전체 자릿수 또는 소수 자릿수를 줄이면 데이터가 잘릴 수 있습니다.
Note
분할된 테이블의 열 데이터 형식은 변경할 수 없습니다.
인덱스에 포함된 열의 데이터 형식은 열이 varchar, nvarchar 또는 varbinary 데이터 형식이고 새로운 크기가 이전 크기보다 크거나 같은 경우가 아니면 변경할 수 없습니다.
기본 키 제약 조건에 포함된 열은 변경할 NOT NULL
NULL
수 없습니다.
보안 Enclave 없이 Always Encrypted를 사용하는 경우 수정되는 열이 암호화된 ENCRYPTED WITH
경우 데이터 형식을 호환되는 데이터 형식(예: )으로 INT
BIGINT
변경할 수 있지만 암호화 설정을 변경할 수는 없습니다.
Always Encrypted를 보안 Enclave와 함께 사용하는 경우 열을 보호하는 열 암호화 키(및 키를 변경하는 경우에는 새 열 암호화 키)에서 Enclave 계산(Enclave 지원 열 마스터 키로 암호화됨)을 지원하는 경우에만 암호화 설정을 변경할 수 있습니다. 자세한 내용은 보안 Enclave를 사용한 Always Encrypted를 참조하세요.
열을 수정할 때 데이터베이스 엔진 시스템 테이블에 행을 추가하고 이전 열 수정 내용을 삭제된 열로 표시하여 각 수정 내용을 추적합니다. 드물게 열을 너무 많이 수정하는 경우 데이터베이스 엔진 레코드 크기 제한에 도달할 수 있습니다. 이 경우 오류 511 또는 1708이 발생합니다. 이러한 오류를 방지하려면 테이블에서 클러스터형 인덱스를 주기적으로 다시 작성하거나 열 수정 횟수를 줄입니다.
column_name
변경, 추가 또는 삭제할 열의 이름입니다. column_name 최댓값은 128자입니다. 새 열의 경우 timestamp 데이터 형식으로 만들어진 열에 대해 column_name을 생략할 수 있습니다. timestamp 데이터 형식 열에 대해 column_name을 지정하지 않으면 timestamp가 이름으로 사용됩니다.
Note
변경되는 테이블의 모든 기존 열 뒤에 새 열이 추가됩니다.
[ type_schema_name. ] type_name
변경된 열의 새 데이터 형식 또는 추가된 열의 데이터 형식입니다. 분할된 테이블의 기존 열에 type_name을 지정할 수 없습니다. type_name은 다음 형식 중 하나일 수 있습니다.
- SQL Server 시스템 데이터 형식
- SQL Server 시스템 데이터 형식을 기반으로 하는 별칭 데이터 형식. 테이블 정의에서 사용할 수 있기 전에 문으로
CREATE TYPE
별칭 데이터 형식을 만듭니다. - .NET Framework 사용자 정의 형식 및 이 형식이 속한 스키마. 테이블 정의에서 사용하기 전에 문을 사용하여 사용자 정의 형식
CREATE TYPE
을 만듭니다.
변경된 열의 type_name에는 다음과 같은 조건이 적용됩니다.
- 이전 데이터 형식은 암시적으로 새 데이터 형식으로 변환 가능해야 합니다.
- type_name은 timestamp가 될 수 없습니다.
- ANSI_NULL 기본값은 항상 켜
ALTER COLUMN
집니다. 지정하지 않으면 열이 null 허용됩니다. -
ANSI_PADDING
패딩은 항상ON
.용입니다.ALTER COLUMN
- 수정된 열이 ID 열이면 new_data_type은 ID 속성을 지원하는 데이터 형식이어야 합니다.
- 현재 설정
SET ARITHABORT
은 무시됩니다.ALTER TABLE
는 마치 로 설정된 것처럼ARITHABORT
작동합니다ON
.
Note
절을 COLLATE
지정하지 않으면 열의 데이터 형식을 변경하면 데이터 정렬이 데이터베이스의 기본 데이터 정렬로 변경됩니다.
precision
지정된 데이터 형식의 전체 자릿수입니다. 유효한 정밀도 값에 대한 자세한 내용은 전체 자릿수, 소수 자릿수 및 길이를 참조하세요.
scale
지정된 데이터 형식의 소수 자릿수입니다. 유효한 배율 값에 대한 자세한 내용은 전체 자릿수, 배율 및 길이를 참조하세요.
max
2^31-1바이트의 문자, 이진 데이터 및 유니코드 데이터를 저장하기 위한 varchar, nvarchar 및 varbinary 데이터 형식에만 적용됩니다.
xml_schema_collection
적용 대상: SQL Server 및 Azure SQL Database.
XML 스키마를 xml 데이터 형식에 연결하기 위해 이 형식에만 적용됩니다. 스키마 컬렉션에 xml 열을 입력하기 전에 먼저 CREATE XML SCHEMA COLLECTION을 사용하여 데이터베이스에 스키마 컬렉션을 만듭니다.
COLLATE <collation_name>
변경된 열에 대한 새 데이터 정렬을 지정합니다. 이를 지정하지 않으면 열에 데이터베이스의 기본 데이터 정렬이 할당됩니다. 데이터 정렬 이름으로는 Windows 데이터 정렬 이름 또는 SQL 데이터 정렬 이름을 사용할 수 있습니다. 목록 및 자세한 내용은 Windows 데이터 정렬 이름 및 SQL Server 데이터 정렬 이름을 참조하세요.
이 절은 COLLATE
char, varchar, nchar 및 nvarchar 데이터 형식의 열만 데이터 정렬을 변경합니다. 사용자 정의 별칭 데이터 형식 열의 데이터 정렬을 변경하려면 별도의 ALTER TABLE
문을 사용하여 열을 SQL Server 시스템 데이터 형식으로 변경합니다. 그런 다음, 해당 데이터 정렬을 변경하고 그 열을 별칭 데이터 형식으로 다시 변경합니다.
ALTER COLUMN
다음 조건 중 하나 이상이 있는 경우 데이터 정렬을 변경할 수 없습니다.
-
CHECK
제약 조건,FOREIGN KEY
제약 조건 또는 계산 열은 변경된 열을 참조합니다. - 모든 인덱스, 통계 또는 전체 텍스트 인덱스가 열에 만들어집니다. 변경된 열에 자동으로 만들어진 통계는 열 데이터 정렬이 변경되면 삭제됩니다.
- 스키마 바인딩된 뷰 또는 함수가 열을 참조합니다.
지원되는 데이터 정렬에 대한 자세한 내용은 COLLATE참조하세요.
NULL | NOT NULL
열에 Null 값 허용 여부를 지정합니다. null 값을 허용하지 않는 열은 기본값이 지정되었거나 테이블이 비어 있는 경우에만 추가 ALTER TABLE
됩니다. 또한 지정 NOT NULL
PERSISTED
한 경우에만 계산 열에 지정할 수 있습니다. 새 열이 Null 값을 허용하고 기본값이 지정되지 않으면 테이블에서 각 행의 새 열은 Null 값을 포함합니다. 새 열에서 null 값을 허용하고 새 열을 사용하여 기본 정의를 추가하는 경우 테이블의 각 기존 행에 대한 기본값을 새 열에 저장하는 데 사용할 WITH VALUES
수 있습니다.
새 열에서 null 값을 허용하지 않고 테이블이 비어 있지 않은 경우 새 열을 사용하여 DEFAULT
정의를 추가해야 합니다. 또한 각 기존 행의 새 열에 자동으로 기본값이 로드됩니다.
제약 조건의 ALTER COLUMN
열을 PRIMARY KEY
제외하고 열을 강제로 NOT NULL
null 값으로 허용하도록 지정할 NULL
수 있습니다. 열에 ALTER COLUMN
null 값이 없는 경우에만 지정할 NOT NULL
수 있습니다. 예를 들어 null 값이 허용되기 전에 일부 값으로 ALTER COLUMN
NOT NULL
업데이트해야 합니다.
UPDATE MyTable SET NullCol = N'some_value' WHERE NullCol IS NULL;
ALTER TABLE MyTable ALTER COLUMN NullCOl NVARCHAR (20) NOT NULL;
또는 문을 사용하여 테이블을 CREATE TABLE
만들거나 ALTER TABLE
변경할 때 데이터베이스 및 세션 설정이 열 정의에 사용되는 데이터 형식의 null 허용 여부를 재정의할 수 있습니다. 항상 열을 계산되지 않은 열로 또는 NOT NULL
비컴퓨트 열로 NULL
명시적으로 정의해야 합니다.
사용자 정의 데이터 형식이 있는 열을 추가할 경우에는 사용자 정의 데이터 형식과 같은 Null 허용 여부를 사용하여 열을 정의해야 합니다. 또한 열의 기본값을 지정합니다. 자세한 내용은 CREATE TABLE을 참조하세요.
Note
NULL
NOT NULL
new_data_type [(precision [, scale ])]도 지정ALTER COLUMN
해야 합니다. 데이터 형식, 정밀도 및 소수 자릿수가 변경되지 않으면 현재 열 값을 지정합니다.
[ {ADD | DROP} ROWGUIDCOL ]
적용 대상: SQL Server 및 Azure SQL Database.
지정된 열에 ROWGUIDCOL
속성이 추가되거나 삭제되도록 지정합니다.
ROWGUIDCOL
는 열이 행 GUID 열임을 나타냅니다. 테이블당 하나의 uniqueidentifier 열만 열로 ROWGUIDCOL
설정할 수 있습니다. 또한 uniqueidentifier 열에 ROWGUIDCOL
만 속성을 할당할 수 있습니다. 사용자 정의 데이터 형식의 열에는 할당 ROWGUIDCOL
할 수 없습니다.
ROWGUIDCOL
는 열에 저장된 값의 고유성을 적용하지 않으며 테이블에 삽입되는 새 행에 대한 값을 자동으로 생성하지 않습니다. 각 열에 대해 고유한 값을 생성하려면 NEWID()
문에서 NEWSEQUENTIALID()
또는 INSERT
함수를 사용합니다. 또는 NEWID()
또는 NEWSEQUENTIALID()
함수를 열의 기본값으로 지정합니다.
[ {ADD | DROP} PERSISTED ]
지정된 열에 PERSISTED
속성이 추가되거나 삭제되도록 지정합니다. 이 열은 결정적 식으로 정의된 계산 열이어야 합니다. 지정된 PERSISTED
열의 경우 데이터베이스 엔진은 계산된 값을 테이블에 물리적으로 저장하고 계산 열이 의존하는 다른 열이 업데이트될 때 값을 업데이트합니다. 계산 열을 로 PERSISTED
표시하면 결정적이지만 정확하지 않은 식에 정의된 계산 열에 인덱스를 만들 수 있습니다. 자세한 내용은 계산 열의 인덱스를 참조하세요.
SET QUOTED_IDENTIFIER
ON
는 계산 열 또는 인덱싱된 뷰에서 인덱스를 만들거나 변경할 때여야 합니다. 자세한 내용은 SET QUOTED_IDENTIFIER를 참조하세요.
분할된 테이블의 분할 열로 사용되는 계산 열은 명시적으로 표시 PERSISTED
되어야 합니다.
Note
Fabric SQL 데이터베이스에서 계산 열은 허용되지만 현재 Fabric OneLake에 미러링되지 않습니다.
DROP NOT FOR REPLICATION
적용 대상: SQL Server 및 Azure SQL Database.
복제 에이전트가 삽입 작업을 수행할 때 ID 열의 값이 증가하도록 지정합니다. column_name이 ID 열인 경우에만 이 열을 지정할 수 있습니다.
SPARSE
열이 스파스 열임을 나타냅니다. 스파스 열의 스토리지는 Null 값에 대해 최적화됩니다. 스파스 열을 .로 NOT NULL
설정할 수 없습니다. 열을 스파스에서 논스파스로 변환하거나 비파열에서 스파스로 변환하는 경우 이 옵션은 명령 실행 기간 동안 테이블을 잠급니다. 절을 사용하여 REBUILD
공간 절약을 회수해야 할 수 있습니다. 스파스 열에 대한 추가 제한 사항 및 자세한 내용은 스파스 열 사용을 참조하세요.
ADD MASKED WITH ( FUNCTION = 'mask_function')
적용 대상: SQL Server 2016(13.x) 이상 버전 및 Azure SQL Database.
동적 데이터 마스크를 지정합니다. mask_function은 적절한 매개 변수를 포함한 마스킹 함수의 이름 입니다. 세 함수를 사용할 수 있습니다.
- default()
- email()
- partial()
- random()
ALTER ANY MASK
사용 권한이 필요합니다.
마스크를 삭제하려면 DROP MASKED
를 사용합니다. 함수 매개 변수는 동적 데이터 마스킹을 참조하세요.
마스크를 추가하고 삭제하려면 권한이 필요합니다 ALTER ANY MASK
.
WITH ( ONLINE = ON | OFF) <열 변경에 적용>
적용 대상: SQL Server 2016(13.x) 이상 버전 및 Azure SQL Database.
테이블을 사용 가능한 상태로 유지하면서 많은 열 변경 작업을 수행할 수 있게 해줍니다. 기본값은 OFF
입니다. 데이터 형식, 열 길이 또는 전체 자릿수, Null 허용 여부, 스파스 및 데이터 정렬과 관련된 열 변경 내용에 대해 온라인 열 변경을 실행할 수 있습니다.
온라인 변경 열을 사용하면 사용자가 만든 열과 자동 통계학에서 작업 기간 동안 ALTER COLUMN
변경된 열을 참조할 수 있으므로 쿼리가 평소와 같이 실행될 수 있습니다. 작업 종료 시 열을 참조하는 자동 통계는 삭제되고 사용자가 만든 통계는 무효화됩니다. 사용자는 작업이 완료된 후 사용자가 생성한 통계를 수동으로 업데이트해야 합니다. 열이 모든 통계나 인덱스에 대한 필터 식의 일부인 경우 열 변경 작업을 수행할 수 없습니다.
온라인 열 변경 작업이 실행되는 동안 해당 열에 의존할 수 있는 모든 DDL 작업(예: 인덱스, 뷰 만들기 또는 수정 등)이 차단되거나 적절한 오류로 인해 실패합니다. 이 동작은 작업이 실행되고 있는 동안 도입된 종속성으로 인해 온라인 열 변경이 실패하지 않도록 보장하지 않습니다.
변경된 열
NOT NULL
NULL
이 비클러스터형 인덱스에서 참조되는 경우 열 변경은 온라인 작업으로 지원되지 않습니다.열이 CHECK 제약 조건에
ALTER
의해 참조되고 연산이 열의 전체 자릿수(숫자 또는 날짜/시간)를 제한하는 경우 온라인ALTER
은 지원되지 않습니다.WAIT_AT_LOW_PRIORITY
옵션은 온라인 열 변경과 함께 사용할 수 없습니다.ALTER COLUMN ... ADD/DROP PERSISTED
는 온라인 열 변경에 지원되지 않습니다.ALTER COLUMN ... ADD/DROP ROWGUIDCOL/NOT FOR REPLICATION
은 온라인 열 변경의 영향을 받지 않습니다.온라인 열 변경은 변경 내용 추적이 설정되었거나 병합 복제의 게시자인 테이블 변경을 지원하지 않습니다.
온라인 열 변경은 CLR 데이터 형식에서의 변경 또는 CLR 데이터 형식으로의 변경을 지원하지 않습니다.
온라인 열 변경은 현재 스키마 컬렉션과 다른 스키마 컬렉션이 포함된 XML 데이터 형식으로의 변경을 지원하지 않습니다.
온라인 열 변경에서는 열을 변경할 수 있는 경우에 대한 제한이 줄어들지 않습니다. 인덱스/통계 등에 의한 참조로 인해 변경에 실패할 수 있습니다.
온라인 열 변경은 동시에 둘 이상의 열 변경을 지원하지 않습니다.
시스템 버전 관리 temporal 테이블에서는 온라인 변경 옵션이 영향을 주지 않습니다.
ALTER
열은 옵션에 대해 지정된 값에 관계없이 온라인으로 실행되지ONLINE
않습니다.
온라인 열 변경의 요구 사항, 제한 및 기능은 다음을 포함한 온라인 인덱스 다시 작성과 유사합니다.
- 테이블에 레거시 LOB 또는 FILESTREAM 열이 포함되어 있거나 테이블에 columnstore 인덱스가 있는 경우 온라인 인덱스 다시 작성은 지원되지 않습니다. 동일한 제한이 온라인 열 변경에도 적용됩니다.
- 기존 열을 변경하려면 원본 열과 새로 만들어진 숨겨진 열에 대한 공간 할당이 필요하므로 두 배의 공간 할당이 필요합니다.
- 온라인 열 변경 작업 동안 잠금 전략은 온라인 인덱스 작성에 사용되는 것과 동일한 잠금 패턴을 따릅니다.
WITH CHECK | WITH NOCHECK
테이블의 데이터가 새로 추가되었거나 다시 사용하도록 설정 FOREIGN KEY
CHECK
되었거나 제약 조건에 대해 유효성을 검사하지 않는지 여부를 지정합니다. 지정 WITH CHECK
하지 않으면 새 제약 조건에 대해 가정되며 WITH NOCHECK
다시 사용하도록 설정된 제약 조건으로 간주됩니다.
기존 데이터에 대한 새로운 CHECK
제약 조건 또는 FOREIGN KEY
제약 조건을 확인하지 않으려면 다음을 사용합니다 WITH NOCHECK
. 이 방법은 꼭 필요한 경우가 아니면 사용하지 않는 것이 좋습니다. 새 제약 조건은 나중에 데이터가 업데이트될 때마다 평가됩니다. 제약 조건이 추가될 WITH NOCHECK
때 표시되지 않는 제약 조건 위반으로 인해 제약 조건을 따르지 않는 데이터로 행을 업데이트하는 경우 향후 업데이트가 실패할 수 있습니다. 쿼리 최적화 프로그램은 정의된 WITH NOCHECK
제약 조건을 고려하지 않습니다. 이러한 제약 조건은 .를 사용하여 ALTER TABLE table WITH CHECK CHECK CONSTRAINT ALL
다시 사용하도록 설정될 때까지 무시됩니다. 자세한 내용은 INSERT 및 UPDATE 문을 사용하여 외래 키 제약 조건 사용 안 함을 참조하세요.
ALTER INDEX index_name
index_name의 버킷 수를 변경하거나 변경하도록 지정합니다.
구문 ALTER TABLE ... ADD/DROP/ALTER INDEX
메모리 최적화 테이블에 대해서만 지원됩니다.
Important
문을 사용하지 ALTER TABLE
않으면 CREATE INDEX, DROP INDEX, ALTER INDEX 및 PAD_INDEX 문은 메모리 최적화 테이블의 인덱스에 대해 지원되지 않습니다.
ADD
하나 이상의 열 정의, 계산 열 정의 또는 테이블 제약 조건이 추가되도록 지정합니다. 또는 시스템이 시스템 버전 관리에 사용하는 열이 추가됩니다. 메모리 최적화 테이블의 경우 인덱스를 추가할 수 있습니다.
Note
변경되는 테이블의 모든 기존 열 뒤에 새 열이 추가됩니다.
Important
문을 사용하지 ALTER TABLE
않으면 CREATE INDEX, DROP INDEX, ALTER INDEX 및 PAD_INDEX 문은 메모리 최적화 테이블의 인덱스에 대해 지원되지 않습니다.
SYSTEM_TIME 기간(system_start_time_column_name, system_end_time_column_name )
적용 대상: SQL Server 2017(14.x) 이상 버전 및 Azure SQL Database.
시스템에서 레코드가 유효한 기간을 기록하기 위해 사용할 열의 이름을 지정합니다. 기존 열을 지정하거나 인수의 ADD PERIOD FOR SYSTEM_TIME
일부로 새 열을 만들 수 있습니다.
datetime2의 데이터 형식으로 열을 설정하고 열 형식을 로 NOT NULL
정의합니다. 마침표 열을 NULL
정의하면 오류가 발생합니다. column_constraint 정의하거나 system_start_time 및 system_end_time 열의 열에 대한 기본값을 지정할 수 있습니다. system_end_time 열에 기본값을 사용하는 방식을 보여 주는 다음 시스템 버전 관리 예의 예 A를 참조하세요.
인수와 함께 이 인수를 SET SYSTEM_VERSIONING
사용하여 기존 테이블을 임시 테이블로 만듭니다. 자세한 내용은 임시 테이블 및 임시 테이블 시작 정보를 참조하세요.
SQL Server 2017(14.x)을 기준으로 사용자는 하나 또는 두 기간 열을 플래그로 HIDDEN
표시하여 열에 대한 값을 반환하지 않도록 이러한 열을 SELECT * FROM <table_name>
암시적으로 숨길 수 있습니다. 기본적으로 기간 열은 숨겨지지 않습니다. 숨겨진 열을 사용하려면 temporal 테이블을 직접 참조하는 모든 쿼리에 이러한 열을 명시적으로 포함해야 합니다.
DROP
하나 이상의 열 정의, 계산 열 정의 또는 테이블 제약 조건을 삭제하거나 시스템이 시스템 버전 관리에 사용할 열에 대한 사양을 삭제하도록 지정합니다.
Note
원장 테이블에 놓인 열은 일시 삭제됩니다. 삭제된 열은 원장 테이블에 남아 있지만 열을 으로 설정 dropped_ledger_table
하여 삭제된 열 sys.tables
1
로 표시됩니다. 삭제된 원장 테이블의 원장 보기는 열을 dropped_ledger_view
sys.tables
으로 설정 1
하여 삭제됨으로 표시됩니다. 삭제된 원장 테이블, 기록 테이블 및 원장 보기는 접두사(MSSQL_DroppedLedgerTable
, MSSQL_DroppedLedgerHistory
, MSSQL_DroppedLedgerView
)를 추가하고 GUID를 원래 이름에 추가하여 이름이 바뀝니다.
제약 조건 constraint_name
테이블에서 constraint_name이 제거되도록 지정합니다. 여러 제약 조건을 나열할 수 있습니다.
sys.check_constraint
, sys.default_constraints
, sys.key_constraints
, sys.foreign_keys
카탈로그 뷰를 쿼리하여 사용자 정의 또는 시스템 제공 제약 조건 이름을 확인할 수 있습니다.
PRIMARY KEY
테이블에 XML 인덱스가 있으면 제약 조건을 삭제할 수 없습니다.
INDEX index_name
index_name이 테이블에서 제거되도록 지정합니다.
구문 ALTER TABLE
ALTER INDEX
ADD
/DROP
/은 메모리 최적화 테이블에 대해서만 지원됩니다.
Important
문을 사용하지 ALTER TABLE
않으면 CREATE INDEX, DROP INDEX, ALTER INDEX 및 PAD_INDEX 문은 메모리 최적화 테이블의 인덱스에 대해 지원되지 않습니다.
열 column_name
테이블에서 constraint_name 또는 column_name이 제거되도록 지정합니다. 여러 열을 나열할 수 있습니다.
다음과 같은 열은 삭제할 수 없습니다.
- 키 열 또는 인덱스로 사용됨
INCLUDE
- ,
FOREIGN KEY
,UNIQUE
또는PRIMARY KEY
제약 조건에CHECK
사용됩니다. - 키워드로 정의되거나 기본 개체에
DEFAULT
바인딩된 기본값과 연결됩니다. - 규칙에 바인딩된 열
Note
열을 삭제해도 해당 열의 디스크 공간은 회수되지 않습니다. 테이블의 행 크기가 한도에 가깝거나 초과한 경우 삭제된 열의 디스크 공간을 회수해야 할 수 있습니다. ALTER INDEX를 사용하여 기존 클러스터형 인덱스를 다시 작성하거나 테이블에 클러스터형 인덱스를 생성하면 공간을 회수할 수 있습니다. LOB 데이터 형식의 삭제 영향에 대한 자세한 내용은 CSS 블로그 항목을 참조하세요.
SYSTEM_TIME 기간
적용 대상: SQL Server 2016(13.x) 이상 버전 및 Azure SQL Database.
시스템에서 시스템 버전 관리용으로 사용하는 열에 대한 사양을 삭제합니다.
WITH <drop_clustered_constraint_option>
하나 이상의 클러스터형 제약 조건 삭제 옵션이 설정되도록 지정합니다.
MAXDOP = max_degree_of_parallelism
적용 대상: SQL Server 및 Azure SQL Database.
작업 중에만 최대 병렬 처리 수준 구성 옵션을 재정의합니다. 자세한 내용은 서버 구성: 최대 병렬 처리 수준을 참조하세요.
MAXDOP
이 옵션을 사용하여 병렬 계획 실행에 사용되는 프로세서 수를 제한합니다. 최대값은 64개입니다.
max_degree_of_parallelism은 다음 값 중 하나일 수 있습니다.
1
병렬 계획이 생성되지 않습니다.
>1
병렬 인덱스 작업에 사용되는 최대 프로세서 수를 지정된 값으로 제한합니다.
0
(기본값)현재 시스템 워크로드에 따라 프로세서의 실제 개수 이하를 사용합니다.
자세한 내용은 병렬 인덱스 작업 구성을 참조하세요.
Note
병렬 인덱스 작업은 일부 SQL Server 버전에서 사용할 수 있습니다. 자세한 내용은 SQL Server 2022의 버전 및 지원하는 기능을 참조하세요.
ONLINE = { ON | OFF } <drop_clustered_constraint_option 적용>
인덱스 작업 중 쿼리 및 데이터 수정에 기본 테이블과 관련 인덱스를 사용할 수 있는지 여부를 지정합니다. 기본값은 OFF
입니다. 작업으로 ONLINE
실행할 REBUILD
수 있습니다.
ON
인덱스 작업 중에 장기 테이블 잠금이 유지되지 않습니다. 인덱스 작업의 주 단계에서는 원본 테이블에 의도 공유(
IS
) 잠금만 유지됩니다. 이 동작을 통해 기본 테이블과 인덱스를 계속 쿼리하거나 업데이트할 수 있습니다. 작업이 시작될 때 짧은 시간 동안 S(공유) 잠금이 원본 개체에 유지됩니다. 작업이 끝나면 짧은 시간 동안 비클러스터형 인덱스가 생성되는 경우에는 원본에 대해 S(공유) 잠금이 획득됩니다. 또는 클러스터형 인덱스를 만들거나 온라인으로 삭제하고 클러스터형 또는 비클러스터형 인덱스를 다시 작성할 때 Sch-M(스키마 수정) 잠금을 획득합니다.ONLINE
는 인덱스가 로컬 임시 테이블에 생성되는 시점으로 설정할ON
수 없습니다. 단일 스레드 힙 다시 작성 작업만 허용됩니다.DDL을
SWITCH
실행하거나 온라인 인덱스를 다시 작성하려면 특정 테이블에서 실행되는 모든 활성 차단 트랜잭션을 완료해야 합니다. 실행할SWITCH
때 또는 다시 빌드 작업을 수행하면 새 트랜잭션이 시작되지 않으며 워크로드 처리량에 큰 영향을 미치고 기본 테이블에 대한 액세스를 일시적으로 지연할 수 있습니다.OFF
인덱스 작업 중에 테이블 잠금이 적용됩니다. 클러스터형 인덱스를 생성, 다시 작성 또는 삭제하거나 비클러스터형 인덱스를 다시 작성 또는 삭제하는 오프라인 인덱스 작업을 통해 테이블의 SCH-M(스키마 수정) 잠금을 획득합니다. 이 잠금이 획득되면 작업 중에 모든 사용자가 기본 테이블에 액세스할 수 없습니다. 비클러스터형 인덱스를 만드는 오프라인 인덱스 작업을 통해 테이블의 S(공유) 잠금을 획득합니다. 이 잠금은 기본 테이블에 대한 업데이트를 방지하지만 문과 같은
SELECT
읽기 작업을 허용합니다. 다중 스레드 힙 다시 작성 작업이 허용됩니다.자세한 내용은 온라인 인덱스 작업의 작동 방식을 참조하세요.
Note
온라인 인덱스 작업은 SQL Server의 모든 버전에서 사용할 수 없습니다. 자세한 내용은 SQL Server 2022의 버전 및 지원하는 기능을 참조하세요.
{ partition_scheme_name(column_name [ ,...로 이동n ] ) | 파일 그룹 | "default" }
적용 대상: SQL Server 및 Azure SQL Database.
현재 클러스터형 인덱스의 리프 수준에 있는 데이터 행을 이동할 위치를 지정합니다. 테이블이 새 위치로 이동됩니다. 이 옵션은 클러스터형 인덱스를 만드는 제약 조건에만 적용됩니다.
Note
이 컨텍스트에서는 default
키워드가 아닙니다. 기본 파일 그룹에 대한 식별자이며, 와 MOVE TO "default"
MOVE TO [default]
같이 구분되어야 합니다. 지정한 QUOTED_IDENTIFIER
경우 "default"
현재 세션에 대한 옵션이어야 ON
합니다. 이 값은 기본 설정입니다. 자세한 내용은 SET QUOTED_IDENTIFIER를 참조하세요.
{ CHECK | NOCHECK } 제약 조건
constraint_name의 설정 여부를 지정합니다. 이 옵션은 제약 조건과 CHECK
함께 FOREIGN KEY
만 사용할 수 있습니다.
NOCHECK
지정되면 제약 조건이 비활성화되고 나중에 열에 대한 삽입 또는 업데이트가 제약 조건과 달리 유효성이 검사되지 않습니다.
DEFAULT
, PRIMARY KEY
제약 UNIQUE
조건을 사용하지 않도록 설정할 수 없습니다.
ALL
옵션을 사용하여 모든 제약 조건을 사용하지 않도록
NOCHECK
설정하거나 옵션을 사용하도록CHECK
지정합니다.
{ ENABLE | DISABLE } TRIGGER
trigger_name의 설정 여부를 지정합니다. 트리거를 해제해도 테이블에는 계속 정의되어 있습니다. 그러나 INSERT
테이블에 대해 명령 UPDATE
문이 DELETE
실행되면 트리거가 다시 활성화될 때까지 트리거의 작업이 수행되지 않습니다.
ALL
테이블의 모든 트리거를 설정하거나 해제하도록 지정합니다.
trigger_name
설정하거나 해제할 트리거의 이름을 지정합니다.
{ ENABLE | DISABLE } CHANGE_TRACKING
적용 대상: SQL Server 및 Azure SQL Database.
테이블에 대해 변경 내용 추적이 설정되는지 여부를 지정합니다. 기본적으로 변경 내용 추적은 비활성화됩니다.
이 옵션은 데이터베이스에 대해 변경 내용 추적이 설정된 경우에만 사용할 수 있습니다. 자세한 내용은 ALTER DATABASE SET 옵션을 참조하세요.
변경 내용 추적을 설정하려면 테이블에 기본 키가 있어야 합니다.
WITH ( TRACK_COLUMNS_UPDATED = { ON | OFF } )
적용 대상: SQL Server 및 Azure SQL Database.
데이터베이스 엔진에서 업데이트된 변경 내용 추적 열을 추적하는지 여부를 지정합니다. 기본값은 OFF
입니다.
SWITCH [ PARTITION source_partition_number_expression ] TO [ schema_name. ] target_table [ PARTITION target_partition_number_expression ]
적용 대상: SQL Server 및 Azure SQL Database.
다음 방법 중 하나를 사용하여 데이터 블록을 전환합니다.
- 테이블의 모든 데이터를 기존의 분할된 테이블에 파티션으로 재할당합니다.
- 분할된 테이블 간에 파티션을 전환합니다.
- 분할된 테이블의 한 파티션에 있는 모든 데이터를 기존의 분할되지 않은 테이블에 재할당합니다.
table이 분할된 테이블인 경우 source_partition_number_expression을 지정해야 합니다. target_table이 분할된 테이블인 경우 target_partition_number_expression을 지정해야 합니다. 테이블의 데이터를 기존의 분할된 테이블에 파티션으로 재할당하거나 분할된 한 테이블의 파티션을 다른 테이블로 전환하는 경우에는 비어 있는 대상 파티션이 있어야 합니다.
한 파티션의 데이터를 재할당하여 단일 테이블을 구성하는 경우 비어 있는 대상 테이블이 이미 존재해야 합니다. 원본 테이블 또는 파티션과 대상 테이블 또는 파티션이 모두 같은 파일 그룹에 있어야 합니다. 해당하는 인덱스 또는 인덱스 파티션도 같은 파일 그룹에 있어야 합니다. 파티션 전환에는 여러 가지 추가 제한 사항이 적용됩니다. table과 target_table은 동일할 수 없습니다. target_table은 여러 부분으로 구성된 식별자일 수 있습니다.
source_partition_number_expression과 target_partition_number_expression은 둘 모두 변수와 함수를 참조할 수 있는 상수 식입니다. 이러한 식은 사용자 정의 형식 변수와 사용자 정의 함수를 포함하며 Transact-SQL 식을 참조할 수 없습니다.
클러스터형 columstore 인덱스가 포함된 분할된 테이블은 분할된 힙처럼 동작합니다.
- 기본 키에는 파티션 키가 포함되어야 합니다.
- 고유 인덱스에는 파티션 키가 포함되어야 합니다. 그러나 기존 고유 인덱스가 있는 파티션 키를 포함할 경우 고유성이 변경될 수 있습니다.
- 파티션을 전환하려면 모든 비클러스터형 인덱스에 파티션 키를 포함해야 합니다.
복제를 사용하는 경우 제한 사항은 SWITCH
분할된 테이블 및 인덱스 복제를 참조하세요.
비클러스터형 columnstore 인덱스는 SQL Server 2016(13.x) 이전 및 버전 V12 이전의 SQL Database에 대해 읽기 전용 형식으로 빌드되었습니다. 비클러스터형 columnstore 인덱스를 현재 형식(업다이블) PARTITION
으로 다시 빌드해야 작업을 실행할 수 있습니다.
Limitations
비클러스터형 인덱스를 포함하여 두 테이블이 동일하게 분할되고 대상 테이블에 비클러스터형 인덱스가 없는 경우 4907 오류가 발생할 수 있습니다.
출력 예제:
Msg 4907, Level 16, State 1, Line 38
'ALTER TABLE SWITCH' statement failed. The table 'MyDB.dbo.PrtTable1' has 4 partitions while index 'MS1' has 6 partitions.
SET ( FILESTREAM_ON = { partition_scheme_name | filestream_filegroup_name | "default" | "NULL" })
적용 대상: SQL Server. Azure SQL Database에서는 FILESTREAM
을 지원하지 않습니다.
FILESTREAM 데이터가 저장되는 위치를 지정합니다.
ALTER TABLE
테이블에 FILESTREAM 열이 SET FILESTREAM_ON
없는 경우에만 절이 성공합니다. 두 번째 ALTER TABLE
문을 사용하여 FILESTREAM 열을 추가할 수 있습니다.
partition_scheme_name을 지정하면 CREATE TABLE에 대한 규칙이 적용됩니다. 테이블은 이미 행 데이터를 위해 분할되어 있고 테이블의 파티션 구성표는 FILESTREAM 파티션 구성표와 동일한 파티션 함수 및 열을 사용해야 합니다.
filestream_filegroup_name은 FILESTREAM 파일 그룹의 이름입니다. 파일 그룹에 CREATE DATABASE 또는 ALTER DATABASE 문을 사용하여 파일 그룹에 대해 정의된 파일이 하나 있어야 합니다. 그렇지 않으면 오류가 발생합니다.
"default"
는 속성이 설정된 FILESTREAM 파일 그룹을 DEFAULT
지정합니다. FILESTREAM 파일 그룹이 없으면 오류가 발생합니다.
"NULL"
는 테이블에 대한 FILESTREAM 파일 그룹에 대한 모든 참조가 제거되도록 지정합니다. All FILESTREAM 열을 먼저 삭제해야 합니다. 테이블과 연결된 모든 FILESTREAM 데이터를 삭제하는 데 사용합니다 SET FILESTREAM_ON = "NULL"
.
SET ( SYSTEM_VERSIONING = { OFF | ON [ ( HISTORY_TABLE = schema_name . history_table_name [ , DATA_CONSISTENCY_CHECK = { ON | OFF } ] ) ] } )
적용 대상: SQL Server 2016(13.x) 이상 버전 및 Azure SQL Database.
테이블의 시스템 버전 관리를 사용 중지하거나 사용합니다. 테이블의 시스템 버전 관리 기능을 사용하도록 설정하기 위해 시스템은 시스템 버전 관리의 데이터 형식, nullability 제약 조건 및 기본 키 제약 조건 요구 사항이 충족되는지 확인합니다. 시스템은 시스템 버전 테이블의 각 레코드 기록을 별도의 기록 테이블에 기록합니다. 인수를 HISTORY_TABLE
사용하지 않으면 이 기록 테이블의 이름은 .입니다 MSSQL_TemporalHistoryFor<primary_table_object_id>
. 기록 테이블이 없는 경우 시스템은 현재 테이블의 스키마와 일치하는 새 기록 테이블을 생성하고, 두 테이블 간에 링크를 만들고, 시스템이 기록 테이블의 현재 테이블에 있는 각 레코드의 기록을 기록할 수 있도록 합니다. HISTORY_TABLE 인수를 사용하여 기존 기록 테이블에 대한 링크를 만들고 해당 테이블을 사용하면 현재 테이블과 지정된 테이블 간에 링크가 생성됩니다. 기존 기록 테이블에 대한 링크를 만드는 경우 데이터 일관성 검사를 수행하도록 선택할 수 있습니다. 이 데이터 일관성 확인을 통해 기존 레코드가 겹치지 않도록 합니다. 기본값은 데이터 일관성 검사를 실행하는 것입니다.
SYSTEM_VERSIONING = ON
절로 정의된 테이블에서 PERIOD FOR SYSTEM_TIME
인수를 사용하여 기존 테이블을 temporal 테이블로 만듭니다. 자세한 내용은 임시 테이블을 참조하세요.
HISTORY_RETENTION_PERIOD = { INFINITE | number { DAY | DAYS | WEEK | WEEKS | MONTH | MONTHS | YEAR | YEARS } }
적용 대상: SQL Server 2017(14.x) 및 Azure SQL Database.
temporal 테이블의 기록 데이터에 대한 유한 또는 무한 보존을 지정합니다. 생략할 경우 무한 보존이 가정됩니다.
DATA_DELETION
적용 대상: Azure SQL Edge‘만’
데이터베이스 내의 테이블에서 오래된 데이터의 보존 정책 기반 정리를 사용하도록 설정합니다. 자세한 내용은 데이터 보존 사용 및 사용 안 함을 참조하세요. 데이터 보존을 사용하도록 설정하려면 다음 매개 변수를 지정해야 합니다.
FILTER_COLUMN = { column_name }
테이블의 행이 사용되지 않는지 여부를 확인하는 데 사용해야 하는 열을 지정합니다. 필터 열에 대해 허용되는 데이터 형식은 다음과 같습니다.
- date
- datetime
- datetime2
- smalldatetime
- datetimeoffset
RETENTION_PERIOD = { INFINITE | number { DAY | DAYS | WEEK | WEEKS | MONTH | MONTHS | YEAR | YEARS } }
테이블에 대한 보존 기간 정책을 지정합니다. 보존 기간은 양의 정수 값과 날짜 부분 단위의 조합으로 지정됩니다.
SET ( LOCK_ESCALATION = { AUTO | TABLE | DISABLE } )
적용 대상: SQL Server 및 Azure SQL Database.
테이블에 대해 허용되는 잠금 에스컬레이션 방법을 지정합니다.
AUTO
이 옵션을 선택하면 SQL Server 데이터베이스 엔진에서 테이블 스키마에 적절한 잠금 에스컬레이션 세분성을 선택할 수 있습니다.
테이블이 분할된 경우 힙 또는 B-트리(HoBT) 세분성에 대한 잠금 에스컬레이션이 허용됩니다. 즉, 파티션 수준으로 에스컬레이션이 허용됩니다. 잠금이 HoBT 수준으로 에스컬레이션되면 나중에 잠금이 세분성으로
TABLE
에스컬레이션되지 않습니다.테이블이 분할되지 않으면 잠금 에스컬레이션이 세분성으로
TABLE
수행됩니다.
TABLE
잠금 에스컬레이션은 테이블이 분할되었는지 여부에 관계없이 테이블 수준 세분성으로 수행됩니다.
TABLE
는 기본값입니다.DISABLE
대부분의 경우 잠금 에스컬레이션이 허용되지 않습니다. 테이블 수준 잠금은 부분적으로 허용됩니다. 예를 들어 직렬화 가능 격리 수준에서 클러스터형 인덱스가 없는 테이블을 검색하면 데이터베이스 엔진에서 테이블 잠금을 사용하여 데이터 무결성을 보호해야 합니다.
REBUILD
REBUILD WITH
구문을 사용하여 분할된 테이블의 모든 파티션을 포함하여 전체 테이블을 다시 빌드합니다. 테이블에 클러스터형 인덱 REBUILD
스가 있는 경우 이 옵션은 클러스터형 인덱스를 다시 작성합니다.
REBUILD
는 작업으로 ONLINE
실행할 수 있습니다.
REBUILD PARTITION
구문을 사용하여 분할된 테이블에서 단일 파티션을 다시 작성합니다.
PARTITION = ALL
적용 대상: SQL Server 및 Azure SQL Database.
파티션 압축 설정을 변경할 때 모든 파티션을 다시 작성합니다.
REBUILD WITH ( <rebuild_option> )
모든 옵션이 클러스터형 인덱스가 있는 테이블에 적용됩니다. 테이블에 클러스터형 인덱스가 없는 경우에는 일부 옵션만 힙 구조에 영향을 줍니다.
작업으로 특정 압축 설정을 지정 REBUILD
하지 않으면 파티션에 대한 현재 압축 설정이 사용됩니다. 현재 설정을 반환하려면 data_compression
카탈로그 뷰에서 sys.partitions
열을 쿼리합니다.
다시 빌드 옵션에 대한 자세한 내용은 ALTER TABLE index_option을 참조하세요.
DATA_COMPRESSION
적용 대상: SQL Server 및 Azure SQL Database.
지정된 테이블, 파티션 번호 또는 파티션 범위에 대한 데이터 압축 옵션을 지정합니다. 옵션은 다음과 같습니다.
NONE
테이블 또는 지정된 파티션은 압축되지 않습니다. 이 옵션은 columnstore 테이블에 적용되지 않습니다.
행
테이블 또는 지정된 파티션은 행 압축을 사용하여 압축됩니다. 이 옵션은 columnstore 테이블에 적용되지 않습니다.
페이지
테이블 또는 지정된 파티션은 페이지 압축을 사용하여 압축됩니다. 이 옵션은 columnstore 테이블에 적용되지 않습니다.
COLUMNSTORE
적용 대상: SQL Server 2014(12.x) 이상 버전 및 Azure SQL Database.
columnstore 테이블에만 적용됩니다.
COLUMNSTORE
는 옵션으로COLUMNSTORE_ARCHIVE
압축된 파티션의 압축을 풉니다. 데이터는 복구될 때 모든 columnstore 테이블에 사용된 columnstore 압축으로 계속 압축됩니다.COLUMNSTORE_ARCHIVE
적용 대상: SQL Server 2014(12.x) 이상 버전 및 Azure SQL Database.
클러스터형 columnstore 인덱스로 저장된 테이블인 columnstore 테이블에만 적용됩니다.
COLUMNSTORE_ARCHIVE
는 지정된 파티션을 더 작은 크기로 압축합니다. 보관을 위해 또는 보다 적은 스토리지가 필요하고 저장 및 검색에 더 많은 시간을 이용할 수 있는 기타 상황에 이 옵션을 사용합니다.여러 파티션을 동시에 다시 작성하려면 index_option을 참조하세요. 테이블에 클러스터형 인덱스가 없는 경우 데이터 압축을 변경하면 힙과 비클러스터형 인덱스가 다시 작성됩니다. 압축에 대한 자세한 내용은 데이터 압축을 참조하세요.
ALTER TABLE REBUILD PARTITION WITH DATA COMPRESSION = ROW
또는PAGE
Microsoft Fabric 미리 보기의 SQL 데이터베이스에서 허용되지 않습니다.
XML_COMPRESSION
적용 대상: SQL Server 2022(16.x) 이상 버전, Azure SQL 데이터베이스, Azure SQL Managed Instance.
테이블의 모든 xml 데이터 형식 열에 대한 XML 압축 옵션을 지정합니다. 옵션은 다음과 같습니다.
ON
xml 데이터 형식을 사용하는 열이 압축됩니다.
OFF
xml 데이터 형식을 사용하는 열이 압축되지 않습니다.
ONLINE = { ON | OFF } <는 single_partition_rebuild_option 적용됩니다.>
인덱스 작업 중 쿼리 및 데이터 수정을 위해 기본 테이블의 단일 파티션 및 관련된 인덱스를 사용할 수 있는지 여부를 지정합니다. 기본값은 OFF
입니다. 작업으로 ONLINE
실행할 REBUILD
수 있습니다.
ON
인덱스 작업 중에 장기 테이블 잠금이 유지되지 않습니다. 인덱스 다시 작성을 시작할 때 테이블에 대한 S-잠금이 필요하고 온라인 인덱스 다시 작성을 종료할 때 테이블에 대한 Sch-M 잠금이 필요합니다. 두 잠금 모두 짧은 메타데이터 잠금이지만 Sch-M 잠금은 모든 차단 트랜잭션이 완료될 때까지 기다려야 합니다. 대기 시간 동안 Sch-M 잠금은 동일 테이블에 액세스할 때 이 잠금 뒤에서 기다리는 다른 모든 트랜잭션을 차단합니다.
Note
온라인 인덱스 다시 작성은 이 섹션의 뒷부분에서 설명하는
low_priority_lock_wait
옵션을 설정할 수 있습니다.OFF
인덱스 작업 중에 테이블 잠금이 적용됩니다. 이 경우 작업 중에 모든 사용자가 기본 테이블에 액세스할 수 없게 됩니다.
column_set_name XML COLUMN_SET FOR ALL_SPARSE_COLUMNS
적용 대상: SQL Server 및 Azure SQL Database.
열 집합의 이름입니다. 열 집합은 구조화된 출력으로 테이블의 모든 스파스 열을 결합하는 형식화되지 않은 XML 표현입니다. 스파스 열을 포함하는 테이블에는 열 집합을 추가할 수 없습니다. 열 집합에 대한 자세한 내용은 열 집합 사용을 참조하세요.
{ ENABLE | DISABLE } FILETABLE_NAMESPACE
적용 대상: SQL Server.
FileTable에 대한 시스템 정의 제약 조건을 사용하거나 사용하지 않도록 설정합니다. FileTable에서만 사용할 수 있습니다.
SET ( FILETABLE_DIRECTORY = directory_name )
적용 대상: SQL Server. Azure SQL Database는 FileTable을 지원하지 않습니다.
Windows 호환 FileTable 디렉터리 이름을 지정합니다. 이 이름은 데이터베이스의 모든 FileTable 디렉터리 이름 중에서 고유해야 합니다. 고유성을 비교할 때는 SQL 데이터 정렬 설정과 관계없이 대/소문자가 구분되지 않습니다. FileTable에서만 사용할 수 있습니다.
REMOTE_DATA_ARCHIVE
적용 대상: SQL Server 2017(14.x) 이상 버전.
테이블에 Stretch Database를 사용하거나 사용하지 않도록 설정합니다. 자세한 내용은 Stretch Database를 참조하세요.
Important
Stretch Database는 SQL Server 2022(16.x) 및 Azure SQL 데이터베이스에서 사용되지 않습니다. 데이터베이스 엔진의 이후 버전에서는 이 기능이 제거됩니다. 새 개발 작업에서는 이 기능을 사용하지 않도록 하고, 현재 이 기능을 사용하는 애플리케이션은 수정하세요.
테이블에 대해 Stretch Database 사용
ON
을 지정하여 테이블에 대해 Stretch를 활성화한 경우 MIGRATION_STATE = OUTBOUND
를 지정하여 데이터 마이그레이션을 즉시 시작하거나 MIGRATION_STATE = PAUSED
를 지정하여 데이터 마이그레이션을 연기해야 합니다. 기본값은 MIGRATION_STATE = OUTBOUND
입니다. 테이블의 Stretch 사용에 대한 자세한 내용은 테이블에서 Stretch Database 활성화를 참조하세요.
Prerequisites. 테이블에 대해 Stretch를 활성화하기 전에 서버 및 데이터베이스에서 Stretch를 활성화해야 합니다. 자세한 내용은 데이터베이스에서 Stretch Database 활성화를 참조하세요.
Permissions. 데이터베이스 또는 테이블에 대해 Stretch를 활성화하려면 db_owner 권한이 필요합니다. 테이블에 대해 Stretch를 사용하도록 설정하려면 테이블에 대한 권한도 필요합니다 ALTER
.
테이블에 대해 Stretch Database 사용 안 함
테이블에 대한 Stretch를 사용 중지할 경우 이미 Azure로 마이그레이션된 원격 데이터에 두 가지 옵션을 사용할 수 있습니다. 자세한 내용은 Stretch Database 비활성화 및 원격 데이터 다시 가져오기를 참조하세요.
테이블에 대해 스트레치를 사용하지 않도록 설정하고 Azure에서 SQL Server로 테이블의 원격 데이터를 다시 복사하려면 다음 명령을 실행합니다. 이 명령은 취소할 수 없습니다.
ALTER TABLE <table_name> SET ( REMOTE_DATA_ARCHIVE ( MIGRATION_STATE = INBOUND ) ) ;
이 작업은 데이터 전송 비용이 소요되며, 취소할 수 없습니다. 자세한 내용은 데이터 전송 가격 정보를 참조하세요.
Azure에서 SQL Server로 모든 원격 데이터를 다시 복사한 후 테이블에서 스트레치가 비활성화됩니다.
테이블에 대해 스트레치를 사용하지 않도록 설정하고 원격 데이터를 중단하려면 다음 명령을 실행합니다.
ALTER TABLE <table_name> SET ( REMOTE_DATA_ARCHIVE = OFF_WITHOUT_DATA_RECOVERY ( MIGRATION_STATE = PAUSED ) ) ;
테이블에 대해 Stretch Database를 사용하지 않도록 설정한 후에는 데이터 마이그레이션이 중지되고 원격 테이블의 결과가 더 이상 쿼리 결과에 포함되지 않습니다.
Stretch를 사용하지 않도록 설정해도 원격 테이블은 제거되지 않습니다. 원격 테이블을 삭제하려면 Azure Portal을 사용하여 삭제합니다.
[ FILTER_PREDICATE = { null | 조건자 } ]
적용 대상: SQL Server 2017(14.x) 이상 버전.
선택적으로 필터 조건자를 지정하여 기록 및 현재 데이터를 모두 포함하는 테이블에서 마이그레이션할 행을 선택합니다. 조건자는 결정적 인라인 테이블 반환 함수를 호출해야 합니다. 자세한 내용은 테이블에서 Stretch Database 활성화 및 필터 함수를 사용하여 마이그레이션할 행 선택- Stretch Database를 참조하세요.
Important
제대로 수행되지 않는 필터 조건자를 제공하면 데이터 마이그레이션 성능도 저하됩니다. Stretch Database는 연산자를 사용하여 CROSS APPLY
필터 조건자를 테이블에 적용합니다.
필터 조건자를 지정하지 않으면 전체 테이블이 마이그레이션됩니다.
필터 조건자를 지정할 때도 지정 MIGRATION_STATE
해야 합니다.
MIGRATION_STATE = { OUTBOUND | 인바운드 | PAUSED }
적용 대상: SQL Server 2017(14.x) 이상 버전.
OUTBOUND
를 지정하여 SQL Server에서 Azure로 데이터를 마이그레이션합니다.INBOUND
를 지정하여 테이블의 원격 데이터를 Azure에서 SQL Server로 다시 복사한 후 테이블에 대해 Stretch를 비활성화합니다. 자세한 내용은 Stretch Database 비활성화 및 원격 데이터 다시 가져오기를 참조하세요.이 작업은 데이터 전송 비용이 소요되며, 취소할 수 없습니다.
PAUSED
를 지정하여 데이터 마이그레이션을 일시 중지하거나 연기합니다. 자세한 내용은 데이터 마이그레이션 일시 중지 및 다시 시작 - Stretch Database를 참조하세요.
WAIT_AT_LOW_PRIORITY
적용 대상: SQL Server 2014(12.x) 이상 버전 및 Azure SQL Database.
온라인 인덱스 다시 작성에서 이 테이블의 차단 작업을 대기해야 합니다.
WAIT_AT_LOW_PRIORITY
는 온라인 인덱스 다시 작성 작업이 우선 순위가 낮은 잠금을 대기하므로 온라인 인덱스 빌드 작업이 대기하는 동안 다른 작업이 계속 수행되도록 합니다. 옵션을 생략하는 WAIT AT LOW PRIORITY
것은 .와 동일합니다 WAIT_AT_LOW_PRIORITY ( MAX_DURATION = 0 minutes, ABORT_AFTER_WAIT = NONE)
.
MAX_DURATION = time [ MINUTES ]
적용 대상: SQL Server 2014(12.x) 이상 버전 및 Azure SQL Database.
DDL 명령을 실행할 때 온라인 인덱스 다시 작성 잠금이 낮은 우선 순위로 대기하는 SWITCH
대기 시간(분 단위로 지정된 정수 값)입니다. 작업이 시간 동안 MAX_DURATION
차단되면 작업 중 ABORT_AFTER_WAIT
하나가 실행됩니다.
MAX_DURATION
시간은 항상 분 단위이며 단어를 MINUTES
생략할 수 있습니다.
ABORT_AFTER_WAIT = { NONE | SELF | BLOCKERS }
적용 대상: SQL Server 2014(12.x) 이상 버전 및 Azure SQL Database.
NONE
보통(일반) 우선 순위로 잠금을 계속 대기합니다.
SELF
SWITCH
아무 작업도 수행하지 않고 현재 실행 중인 온라인 인덱스 다시 작성 DDL 작업을 종료합니다.BLOCKERS
작업을 계속할 수 있도록 현재 또는 온라인 인덱스 다시 작성 DDL 작업을 차단하는
SWITCH
모든 사용자 트랜잭션을 종료합니다.ALTER ANY CONNECTION
사용 권한이 필요합니다.
IF EXISTS
적용 대상: SQL Server 2016(13.x) 이상 버전 및 Azure SQL Database.
이미 있는 열 또는 제약 조건을 조건부로 삭제합니다.
RESUMABLE = { ON | OFF}
적용 대상: SQL Server 2022(16.x) 이상 버전.
ALTER TABLE ADD CONSTRAINT
작업이 다시 시작될 수 있는지 여부를 지정합니다. 테이블 제약 조건 추가 작업은 ON
일 때 다시 시작할 수 있습니다. 테이블 제약 조건 추가 작업은 다음과 같은 경우 OFF
다시 시작되지 않습니다. 기본값은 OFF
입니다.
RESUMABLE
옵션은 ALTER TABLE table_constraint에서 ALTER TABLE index_option의 일부로 사용할 수 있습니다.
MAX_DURATION
(requiresONLINE = ON
)와 함께 RESUMABLE = ON
사용하면 일시 중지되기 전에 다시 시작 가능한 온라인 추가 제약 조건 작업이 실행되는 시간(분 단위로 지정된 정수 값)을 나타냅니다. 지정하지 않으면 작업이 완료될 때까지 계속됩니다.
다시 시작 가능한 ALTER TABLE ADD CONSTRAINT
작업을 사용하도록 설정하고 사용하는 방법에 대한 자세한 내용은 다시 시작 가능한 테이블 추가 제약 조건을 참조하세요.
Remarks
새 데이터 행을 추가하려면INSERT를 사용합니다. 데이터 행을 제거하려면 DELETE 또는 TRUNCATE TABLE을 사용합니다. 기존 행의 값을 변경하려면 UPDATE를 사용합니다.
프로시저 캐시에 테이블을 ALTER TABLE
참조하는 실행 계획이 있는 경우 다음 실행 시 다시 컴파일되도록 표시합니다.
Microsoft Fabric Preview의 SQL 데이터베이스에서 일부 테이블 기능을 만들 수 있지만 Fabric OneLake에 미러링되지는 않습니다. 자세한 내용은 패브릭 SQL 데이터베이스 미러링에 대한 제한 사항(미리 보기)을 참조하세요.
열 크기 변경
열 데이터 형식의 새 크기를 지정하여 열의 길이, 전체 자릿수 또는 소수 자릿수를 변경할 수 있습니다. 절을 ALTER COLUMN
사용합니다. 열에 데이터가 있는 경우 새 크기는 데이터의 최대 크기보다 작을 수 없습니다. 또한 열이 varchar, nvarchar 또는 varbinary 데이터 형식이고 인덱스가 제약 조건의 PRIMARY KEY
결과가 아닌 경우 인덱스의 열을 정의할 수 없습니다.
열 정의 변경이라는 짧은 섹션의 예를 참조하세요.
잠금 및 ALTER TABLE
구현에서 지정한 변경 내용이 즉시 구현됩니다 ALTER TABLE
. 변경 내용에 테이블 ALTER TABLE
의 행을 수정해야 하는 경우 행을 업데이트합니다.
ALTER TABLE
는 테이블에 대한 스키마 수정(Sch-M) 잠금을 획득하여 마지막에 짧은 Sch-M 잠금이 필요한 온라인 인덱스 작업을 제외하고 변경 중에 다른 연결이 테이블에 대한 메타데이터도 참조하지 않도록 합니다.
ALTER TABLE...SWITCH
작업에서 원본 및 대상 테이블 모두에 대해 잠금이 획득됩니다. 테이블의 수정 사항이 기록되며 완전히 복구 가능합니다. 열 삭제 또는 일부 SQL Server 버전에서 기본값으로 열을 추가하는 NOT NULL
등 큰 테이블의 모든 행에 영향을 주는 변경 내용은 많은 로그 레코드를 완료하고 생성하는 데 시간이 오래 걸릴 수 있습니다. 많은 행에 영향을 주는 모든 INSERT
UPDATE
문 또는 DELETE
문과 동일한 주의로 이러한 ALTER TABLE
문을 실행합니다.
Microsoft Fabric의 Warehouse에 적용됩니다.
ALTER TABLE
는 명시적 트랜잭션의 일부가 될 수 없습니다.
파티션 스위치에 대한 확장 이벤트(XEvents)
다음 XEvents는 온라인 인덱스 다시 작성과 관련이 ALTER TABLE ... SWITCH PARTITION
있습니다.
- lock_request_priority_state
- process_killed_by_abort_blockers
- ddl_with_wait_at_low_priority
NOT NULL 열을 온라인 작업으로 추가
SQL Server 2012(11.x) Enterprise 버전 이상 버전에서 기본값이 있는 열을 추가하는 NOT NULL
것은 기본값이 런타임 상수인 경우 온라인 작업입니다. 즉, 테이블의 기존 행은 작업 중에 업데이트되지 않으므로 테이블의 행 수에도 불구하고 작업이 거의 즉시 완료됩니다. 대신 기본값은 테이블의 메타데이터에만 저장되고 이러한 행에 액세스하는 쿼리에 필요한 경우 해당 값이 조회됩니다. 이 동작은 자동입니다. 구문 이외의 온라인 작업을 구현하는 데 추가 구문이 ADD COLUMN
필요하지 않습니다. 런타임 상수는 테이블의 각 행에 대해 해당 결정성과 관계없이 런타임에 동일한 값을 생성하는 식입니다. 예를 들어 상수 식 "My temporary data"
또는 시스템 함수 GETUTCDATETIME()
는 런타임 상수입니다. 이와 달리 NEWID()
또는 NEWSEQUENTIALID()
함수는 테이블의 각 행에 대해 고유 값이 생성되므로 런타임 상수가 아닙니다.
NOT NULL
런타임 상수가 아닌 기본값이 있는 열을 추가하는 것은 항상 오프라인으로 실행되며 작업 기간 동안 배타적(Sch-M) 잠금을 획득합니다.
기존 행은 메타데이터에 저장된 값을 참조하는 반면, 기본값은 새로 삽입되는 행에 대한 새 행에 저장되고 열에 대한 다른 값을 지정하지 않습니다. 메타데이터에 저장된 기본값은 행이 업데이트될 때(문에 실제 열이 지정 UPDATE
되지 않은 경우에도) 또는 테이블 또는 클러스터형 인덱스를 다시 작성할 때 기존 행으로 이동합니다.
varchar(max), nvarchar(max), varbinary(max), xml, text, ntext, image, hierarchyid, geometry, geography 또는 CLR 사용자 정의 형식의 열은 온라인 작업에서 추가할 수 없습니다. 열을 온라인으로 추가할 수 없으며, 온라인으로 추가하면 최대로 가능한 행 크기가 8,060바이트 제한을 초과합니다. 이러한 경우 열은 오프라인 작업으로 추가됩니다.
병렬 계획 실행
SQL Server 2012(11.x) Enterprise 버전 이상 버전에서는 단일 ALTER TABLE ADD
(인덱스 기반) 또는 DROP
(클러스터형 인덱스) CONSTRAINT
CONSTRAINT
문을 실행하는 데 사용되는 프로세서 수는 최대 병렬 처리 수준 구성 옵션 및 현재 워크로드에 따라 결정됩니다. 데이터베이스 엔진이 시스템에서 진행 중인 작업이 많음을 감지하면 작업의 병렬 처리 수준은 문 실행 시작 전에 자동으로 감소됩니다. 옵션을 지정 MAXDOP
하여 문을 실행하는 데 사용되는 프로세서 수를 수동으로 구성할 수 있습니다. 자세한 내용은 서버 구성: 최대 병렬 처리 수준을 참조하세요.
분할된 테이블
분할된 테이블을 포함하는 SWITCH 작업을 수행하는 것 외에도 분할되지 않은 테이블에 사용되는 것처럼 분할된 테이블의 열, 제약 조건 및 트리거의 상태를 변경하는 데 사용합니다 ALTER TABLE
. 그러나 이 문을 사용하여 테이블 자체가 분할되는 방식을 변경할 수는 없습니다. 분할된 테이블을 재분할하려면 ALTER PARTITION SCHEME 및 ALTER PARTITION FUNCTION을 사용합니다. 또한 분할된 테이블의 열 데이터 형식을 변경할 수 없습니다.
스키마 바운드 뷰가 있는 테이블의 제한 사항
스키마 바인딩 뷰가 있는 테이블의 문에 적용되는 ALTER TABLE
제한 사항은 간단한 인덱스로 테이블을 수정할 때 현재 적용되는 제한 사항과 동일합니다. 즉, 열을 추가할 수는 있지만 스키마 바운드 뷰에 포함된 열을 제거하거나 변경하는 것은 허용되지 않습니다. 문에서 ALTER TABLE
스키마 바인딩된 뷰 ALTER TABLE
에 사용되는 열을 변경해야 하는 경우 실패하고 데이터베이스 엔진에서 오류 메시지가 발생합니다. 스키마 바인딩 및 인덱싱된 뷰에 대한 자세한 내용은 CREATE VIEW를 참조하세요.
기본 테이블을 참조하는 스키마 바운드 뷰를 만들어도 해당 테이블에서 트리거를 추가하거나 제거하는 데 영향을 주지 않습니다.
인덱스 및 ALTER TABLE
제약 조건의 일부로 만들어진 인덱스는 제약 조건을 삭제하면 같이 삭제됩니다. 를 사용하여 CREATE INDEX
만든 인덱스를 삭제해야 DROP INDEX
합니다. 이 ALTER INDEX
문을 사용하여 제약 조건 정의의 인덱스 부분을 다시 작성합니다. 제약 조건을 삭제하고 추가 ALTER TABLE
하지 않아도 됩니다.
열을 제거하려면 먼저 해당 열을 기반으로 하는 인덱스와 제약 조건을 모두 제거해야 합니다.
클러스터형 인덱스를 만든 제약 조건을 삭제하면 클러스터형 인덱스의 리프 수준에 저장된 데이터 행이 비클러스터형 테이블에 저장됩니다. 옵션을 지정하여 클러스터형 인덱스 삭제 및 결과 테이블을 단일 트랜잭션의 다른 파일 그룹 또는 파티션 구성표로 이동할 수 있습니다 MOVE TO
. 이 MOVE TO
옵션에는 다음과 같은 제한 사항이 있습니다.
MOVE TO
인덱싱된 뷰 또는 비클러스터형 인덱스에는 유효하지 않습니다.파티션 구성표 또는 파일 그룹이 이미 있어야 합니다.
지정되지 않은 경우
MOVE TO
테이블은 클러스터형 인덱스용으로 정의된 것과 동일한 파티션 구성표 또는 파일 그룹에 있습니다.
클러스터형 인덱스를 삭제할 때 트랜잭션이 기본 데이터 및 연결된 비클러스터형 인덱스에 대한 쿼리 및 수정을 차단하지 않도록 DROP INDEX
옵션을 지정 ONLINE = ON
합니다.
ONLINE = ON
에는 다음과 같은 제한 사항이 있습니다.
-
ONLINE = ON
은 비활성화된 클러스터형 인덱스에 유효하지 않습니다. 사용 안 함 인덱스는 .를 사용하여ONLINE = OFF
삭제해야 합니다. - 한 번에 하나의 인덱스만 삭제할 수 있습니다.
-
ONLINE = ON
는 인덱싱된 뷰, 비클러스터형 인덱스 또는 로컬 임시 테이블의 인덱스에 유효하지 않습니다. -
ONLINE = ON
는 columnstore 인덱스에 유효하지 않습니다.
클러스터형 인덱스를 삭제하려면 기존 클러스터형 인덱스와 크기가 같은 임시 디스크 공간이 필요합니다. 이 추가 공간은 작업이 완료되면 바로 해제됩니다.
Note
아래에 <drop_clustered_constraint_option>
나열된 옵션은 테이블의 클러스터형 인덱스에 적용되며 뷰 또는 비클러스터형 인덱스의 클러스터형 인덱스에는 적용할 수 없습니다.
스키마 변경 내용을 복제합니다
SQL Server 게시자에서 게시된 테이블에서 실행 ALTER TABLE
하면 기본적으로 해당 변경 내용이 모든 SQL Server 구독자에게 전파됩니다. 이 기능에 몇 가지 제한이 있습니다. 이 기능은 사용 중지할 수 있습니다. 자세한 내용은 게시 데이터베이스의 스키마 변경을 참조하세요.
데이터 압축
시스템 테이블에는 압축을 사용할 수 없습니다. 테이블이 힙인 경우 모드에 대한 ONLINE
다시 작성 작업은 단일 스레드입니다. 다중 스레드 힙 다시 작성 작업에 모드를 사용합니다 OFFLINE
. 데이터 압축에 대한 자세한 내용은 데이터 압축을 참조하세요.
압축 상태 변경이 테이블, 인덱스 또는 파티션에 미치는 영향을 평가하려면 sp_estimate_data_compression_savings 시스템 저장 프로시저를 사용합니다.
다음은 분할된 테이블에 적용되는 제한 사항입니다.
- 테이블에 정렬되지 않은 인덱스가 있으면 단일 파티션의 압축 설정을 변경할 수 없습니다.
-
ALTER TABLE <table> REBUILD PARTITION
... 구문은 지정된 파티션을 다시 빌드합니다. -
ALTER TABLE <table> REBUILD WITH
... 구문은 모든 파티션을 다시 빌드합니다.
ntext 열 삭제
사용되지 않는 ntext 데이터 형식을 사용하여 열을 삭제하는 경우 삭제된 데이터의 정리는 모든 행에서 직렬화된 작업으로 발생합니다. 정리에는 시간이 오래 걸릴 수 있습니다. 행이 많은 테이블에서 ntext 열을 삭제하는 경우 ntext 열을 먼저 값으로 NULL
업데이트한 다음 열을 삭제합니다. 이 작업을 병렬 작업으로 실행하여 훨씬 더 빠르게 수행할 수 있습니다.
온라인 인덱스 다시 작성
온라인 인덱스 다시 작성을 위해 DDL 문을 실행하려면 특정 테이블에서 실행 중인 모든 활성 차단 트랜잭션이 완료되어야 합니다. 온라인 인덱스 다시 작성이 시작되면 이 테이블에서 실행을 시작할 준비가 되어 있는 모든 새로운 트랜잭션이 차단됩니다. 온라인 인덱스 다시 작성에 대한 잠금 기간은 짧지만 특정 테이블에서 열려 있는 모든 트랜잭션이 완료될 때까지 기다리고 새로운 트랜잭션이 시작되지 않도록 차단하면 처리량에 상당한 영향을 줄 수 있습니다. 이로 인해 워크로드 속도가 느려지거나 시간 제한이 발생할 수 있으며, 기본 테이블에 대한 액세스가 크게 제한될 수 있습니다. 이 WAIT_AT_LOW_PRIORITY
옵션을 사용하면 DBA가 온라인 인덱스 다시 작성에 필요한 S-lock 및 Sch-M 잠금을 관리할 수 있습니다. 대기 시간(MAX_DURATION = n [minutes])
()에 차단 작업이 없는 경우 다음 세 가지 경우 모두 온라인 인덱스 BLOCKERS
NONE
SELF
다시 작성이 대기하지 않고 즉시 실행되고 DDL 문이 완료됩니다.
호환성 지원
이 문은 ALTER TABLE
두 부분으로 구성된(schema.object
) 테이블 이름만 지원합니다. SQL Server에서는 다음 형식을 사용하여 테이블 이름을 지정하면 컴파일 시 오류 117이 발생합니다.
server.database.schema.table
.database.schema.table
..schema.table
이전 버전에서는 server.database.schema.table
형식을 지정할 경우 오류 4902가 반환되었습니다.
.database.schema.table
형식 또는 ..schema.table
형식 지정은 성공했습니다.
이 문제를 해결하려면 네 부분으로 구성된 접두사를 사용하지 않아야 합니다.
Permissions
ALTER
테이블에 대한 권한이 필요합니다.
ALTER TABLE
사용 권한은 문과 관련된 ALTER TABLE SWITCH
두 테이블에 모두 적용됩니다. 전환된 데이터는 모두 대상 테이블의 보안을 상속합니다.
문에서 ALTER TABLE
CLR(공용 언어 런타임) 사용자 정의 형식 또는 별칭 데이터 형식 REFERENCES
으로 열을 정의한 경우 형식에 대한 권한이 필요합니다.
테이블의 행을 업데이트하는 열을 추가하거나 변경하려면 테이블에 대한 권한이 필요합니다 UPDATE
. 예를 들어 기본값이 있는 NOT NULL
열을 추가하거나 테이블이 비어 있지 않으면 ID 열을 추가합니다.
Examples
이 문서의 코드 샘플은 AdventureWorks2022
홈페이지에서 다운로드할 수 있는 데이터베이스 또는 AdventureWorksDW2022
샘플 데이터베이스를 사용합니다.
Category | 중요한 구문 요소 |
---|---|
열 및 제약 조건 추가 |
ADD ; PRIMARY KEY 인덱스 옵션, 스파스 열 및 열 집합 사용 |
열 및 제약 조건 삭제 | DROP |
열 정의 변경 | 데이터 형식 변경; 열 크기 변경; 조교 |
테이블 정의 변경 |
DATA_COMPRESSION ; SWITCH PARTITION ; ; LOCK ESCALATION 변경 내용 추적 |
제약 조건 및 트리거 해제/설정 |
CHECK ; NO CHECK ; ; ENABLE TRIGGER DISABLE TRIGGER |
온라인 작업 | ONLINE |
시스템 버전 관리 | SYSTEM_VERSIONING |
열 및 제약 조건 추가
이 섹션의 예에서는 테이블에 열 및 제약 조건을 추가하는 방법을 보여 줍니다.
A. 새 열 추가
다음 예제에서는 null 값을 허용하고 정의를 통해 DEFAULT
제공된 값이 없는 열을 추가합니다. 새 열에는 각 행에 .NULL
CREATE TABLE dbo.doc_exa (column_a INT);
GO
ALTER TABLE dbo.doc_exa
ADD column_b VARCHAR (20) NULL;
GO
B. 제약 조건이 있는 열 추가
다음 예에서는 UNIQUE
제약 조건이 있는 새 열을 추가합니다.
CREATE TABLE dbo.doc_exc (column_a INT);
GO
ALTER TABLE dbo.doc_exc
ADD column_b VARCHAR (20) NULL
CONSTRAINT exb_unique UNIQUE;
GO
EXECUTE sp_help doc_exc;
GO
DROP TABLE dbo.doc_exc;
GO
C. 확인되지 않은 CHECK 제약 조건을 기존 열에 추가
다음 예에서는 테이블의 기존 열에 제약 조건을 추가합니다. 이 열에 제약 조건을 위반하는 값이 있습니다. 따라서 기존 행에서 제약 조건이 위반되지 않도록 하고 제약 조건을 추가할 수 있도록 WITH NOCHECK
를 사용합니다.
CREATE TABLE dbo.doc_exd (column_a INT);
GO
INSERT INTO dbo.doc_exd VALUES (-1);
GO
ALTER TABLE dbo.doc_exd WITH NOCHECK
ADD CONSTRAINT exd_check CHECK (column_a > 1);
GO
EXECUTE sp_help doc_exd;
GO
DROP TABLE dbo.doc_exd;
GO
D. 기존 열에 DEFAULT 제약 조건 추가
다음 예제에서는 두 개의 열이 있는 테이블을 만들고 첫 번째 열에 값을 삽입하고 다른 열은 그대로 유지합니다 NULL
. 그런 다음 DEFAULT
제약 조건이 두 번째 열에 추가됩니다. 기본값이 적용되었는지 확인하기 위해 다른 값이 첫 번째 열에 삽입되고 테이블이 쿼리됩니다.
CREATE TABLE dbo.doc_exz
(
column_a INT,
column_b INT
);
GO
INSERT INTO dbo.doc_exz (column_a) VALUES (7);
GO
ALTER TABLE dbo.doc_exz
ADD CONSTRAINT col_b_def
DEFAULT 50 FOR column_b;
GO
INSERT INTO dbo.doc_exz (column_a) VALUES (10);
GO
SELECT * FROM dbo.doc_exz;
GO
DROP TABLE dbo.doc_exz;
GO
E. 제약 조건이 있는 여러 열 추가
다음 예에서는 제약 조건이 정의된 여러 열을 새로 추가합니다. 첫 번째 새 열은 IDENTITY
속성을 가집니다. 테이블에서 각 행의 ID 열에는 새 증분 값이 있습니다.
CREATE TABLE dbo.doc_exe
(
column_a INT
CONSTRAINT column_a_un UNIQUE
);
GO
ALTER TABLE dbo.doc_exe
-- Add a PRIMARY KEY identity column.
ADD column_b INT IDENTITY
CONSTRAINT column_b_pk PRIMARY KEY,
-- Add a column that references another column in the same table.
column_c INT NULL
CONSTRAINT column_c_fk FOREIGN KEY REFERENCES doc_exe (column_a),
-- Add a column with a constraint to enforce that
-- nonnull data is in a valid telephone number format.
column_d VARCHAR (16) NULL
CONSTRAINT column_d_chk CHECK (column_d LIKE '[0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]'
OR column_d LIKE '([0-9][0-9][0-9]) [0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]'),
-- Add a nonnull column with a default.
column_e DECIMAL (3, 3)
CONSTRAINT column_e_default DEFAULT .081;
GO
EXECUTE sp_help doc_exe;
GO
DROP TABLE dbo.doc_exe;
GO
F. 기본값을 사용하여 nullable 열 추가
다음 예에서는 DEFAULT
정의가 있는 Null 허용 열을 추가하고 WITH VALUES
를 사용하여 테이블의 각 기존 행에 대한 값을 제공합니다.
WITH VALUES
사용되지 않으면 각 행의 값 NULL
이 새 열에 있습니다.
CREATE TABLE dbo.doc_exf (column_a INT);
GO
INSERT INTO dbo.doc_exf VALUES (1);
GO
ALTER TABLE dbo.doc_exf
ADD AddDate SMALLDATETIME
CONSTRAINT AddDateDflt DEFAULT GETDATE() WITH VALUES NULL;
GO
DROP TABLE dbo.doc_exf;
GO
G. 인덱스 또는 데이터 압축 옵션을 사용하여 PRIMARY KEY 제약 조건 만들기
다음 예제에서는 제약 조건을 PRIMARY KEY
만들고 옵션을 FILLFACTOR
ONLINE
PAD_INDEX
설정합니다.PK_TransactionHistoryArchive_TransactionID
결과 클러스터형 인덱스는 제약 조건과 이름이 같습니다.
적용 대상: SQL Server 및 Azure SQL Database.
USE AdventureWorks2022;
GO
ALTER TABLE Production.TransactionHistoryArchive WITH NOCHECK
ADD CONSTRAINT PK_TransactionHistoryArchive_TransactionID
PRIMARY KEY CLUSTERED (TransactionID) WITH (FILLFACTOR = 75, ONLINE = ON, PAD_INDEX = ON);
GO
이와 비슷한 예제는 클러스터형 기본 키를 적용하는 동안 페이지 압축을 적용합니다.
USE AdventureWorks2022;
GO
ALTER TABLE Production.TransactionHistoryArchive WITH NOCHECK
ADD CONSTRAINT PK_TransactionHistoryArchive_TransactionID
PRIMARY KEY CLUSTERED (TransactionID) WITH (DATA_COMPRESSION = PAGE);
GO
H. 스파스 열 추가
다음 예에서는 T1 테이블의 스파스 열 추가 및 수정을 보여 줍니다.
T1
테이블을 만들기 위한 코드는 다음과 같습니다.
CREATE TABLE T1
(
C1 INT PRIMARY KEY,
C2 VARCHAR (50) SPARSE NULL,
C3 INT SPARSE NULL,
C4 INT
);
GO
추가 스파스 열 C5
를 추가하려면 다음 문을 실행합니다.
ALTER TABLE T1
ADD C5 CHAR (100) SPARSE NULL;
GO
스파스가 아닌 열 C4
를 스파스 열로 변환하려면 다음 문을 실행합니다.
ALTER TABLE T1
ALTER COLUMN C4 ADD SPARSE;
GO
C4
스파스 열을 스파스가 아닌 열로 변환하려면 다음 명령문을 실행합니다.
ALTER TABLE T1
ALTER COLUMN C4 DROP SPARSE;
GO
I. 열 집합 추가
다음 예에서는 T2
테이블에 열을 추가하는 방법을 보여 줍니다. 스파스 열이 이미 포함되어 있는 테이블에는 열 집합을 추가할 수 없습니다.
T2
테이블을 만들기 위한 코드는 다음과 같습니다.
CREATE TABLE T2
(
C1 INT PRIMARY KEY,
C2 VARCHAR (50) NULL,
C3 INT NULL,
C4 INT
);
GO
다음 3개의 문은 CS
라는 열 집합을 추가한 다음, C2
및 C3
열을 SPARSE로 수정합니다.
ALTER TABLE T2
ADD CS XML COLUMN_SET FOR ALL_SPARSE_COLUMNS;
GO
ALTER TABLE T2
ALTER COLUMN C2 ADD SPARSE;
GO
ALTER TABLE T2
ALTER COLUMN C3 ADD SPARSE;
GO
J. 암호화된 열 추가
다음 명령문은 PromotionCode
라는 암호화 열을 추가합니다.
ALTER TABLE Customers
ADD PromotionCode NVARCHAR (100)
ENCRYPTED WITH (
COLUMN_ENCRYPTION_KEY = MyCEK,
ENCRYPTION_TYPE = RANDOMIZED,
ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
);
K. 다시 시작 가능한 작업을 사용하여 기본 키 추가
ALTER TABLE
이 240분인 열 (a)에 클러스터된 기본 키를 추가하기 위한 다시 시작할 수 있는 MAX_DURATION
작업입니다.
ALTER TABLE table1
ADD CONSTRAINT PK_Constrain PRIMARY KEY CLUSTERED (a)
WITH (ONLINE = ON, MAXDOP = 2, RESUMABLE = ON, MAX_DURATION = 240);
열 및 제약 조건 삭제
이 섹션의 예에서는 열 및 제약 조건을 삭제하는 방법을 보여 줍니다.
A. 열 또는 열 삭제
첫 번째 예에서는 테이블을 수정하여 열을 제거합니다. 두 번째 예에서는 여러 열을 제거합니다.
CREATE TABLE dbo.doc_exb
(
column_a INT,
column_b VARCHAR (20) NULL,
column_c DATETIME,
column_d INT
);
GO
-- Remove a single column.
ALTER TABLE dbo.doc_exb DROP COLUMN column_b;
GO
-- Remove multiple columns.
ALTER TABLE dbo.doc_exb DROP COLUMN column_c, column_d;
B. 제약 조건 및 열 삭제
첫 번째 예에서는 테이블에서 UNIQUE
제약 조건을 제거합니다. 두 번째 예에서는 제약 조건 두 개와 열 하나를 제거합니다.
CREATE TABLE dbo.doc_exc
(
column_a INT NOT NULL
CONSTRAINT my_constraint UNIQUE
);
GO
-- Example 1. Remove a single constraint.
ALTER TABLE dbo.doc_exc DROP my_constraint;
GO
DROP TABLE dbo.doc_exc;
GO
CREATE TABLE dbo.doc_exc
(
column_a INT NOT NULL
CONSTRAINT my_constraint UNIQUE,
column_b INT NOT NULL
CONSTRAINT my_pk_constraint PRIMARY KEY
);
GO
-- Example 2. Remove two constraints and one column
-- The keyword CONSTRAINT is optional. The keyword COLUMN is required.
ALTER TABLE dbo.doc_exc
DROP CONSTRAINT my_constraint, my_pk_constraint, COLUMN column_b;
GO
C. ONLINE 모드에서 PRIMARY KEY 제약 조건 삭제
다음 예제에서는 옵션이 .로 설정된 제약 조건을 ONLINE
삭제합니다 PRIMARY KEY
ON
.
ALTER TABLE Production.TransactionHistoryArchive
DROP CONSTRAINT PK_TransactionHistoryArchive_TransactionID
WITH (ONLINE = ON);
GO
D. FOREIGN KEY 제약 조건 추가 및 삭제
다음 예에서는 ContactBackup
테이블을 만든 다음 FOREIGN KEY
테이블을 참조하는 Person.Person
제약 조건을 추가했다가 다시 FOREIGN KEY
제약 조건을 삭제하여 테이블을 변경합니다.
CREATE TABLE Person.ContactBackup (ContactID INT);
GO
ALTER TABLE Person.ContactBackup
ADD CONSTRAINT FK_ContactBackup_Contact
FOREIGN KEY (ContactID) REFERENCES Person.Person (BusinessEntityID);
GO
ALTER TABLE Person.ContactBackup
DROP CONSTRAINT FK_ContactBackup_Contact;
GO
DROP TABLE Person.ContactBackup;
열 정의 변경
A. 열의 데이터 형식 변경하기
다음 예에서는 테이블의 열을 INT
에서 DECIMAL
로 변경합니다.
CREATE TABLE dbo.doc_exy (column_a INT);
GO
INSERT INTO dbo.doc_exy (column_a) VALUES (10);
GO
ALTER TABLE dbo.doc_exy ALTER COLUMN column_a DECIMAL (5, 2);
GO
DROP TABLE dbo.doc_exy;
GO
B. 열 크기 변경
다음 예에서는 varchar 열의 크기와 decimal 열의 전체 자릿수 및 소수 자릿수를 늘립니다. 열에 데이터가 포함되어 있으므로 열 크기는 늘리기만 가능합니다. 또한 col_a
는 고유 인덱스에 정의됩니다. 데이터 형식이 varchar이고 인덱스가 제약 조건의 PRIMARY KEY
col_a
결과가 아니므로 크기는 계속 늘릴 수 있습니다.
-- Create a two-column table with a unique index on the varchar column.
CREATE TABLE dbo.doc_exy
(
col_a VARCHAR (5) UNIQUE NOT NULL,
col_b DECIMAL (4, 2)
);
GO
INSERT INTO dbo.doc_exy VALUES ('Test', 99.99);
GO
-- Verify the current column size.
SELECT name,
TYPE_NAME(system_type_id),
max_length,
precision,
scale
FROM sys.columns
WHERE object_id = OBJECT_ID(N'dbo.doc_exy');
GO
-- Increase the size of the varchar column.
ALTER TABLE dbo.doc_exy ALTER COLUMN col_a VARCHAR (25);
GO
-- Increase the scale and precision of the decimal column.
ALTER TABLE dbo.doc_exy ALTER COLUMN col_b DECIMAL (10, 4);
GO
-- Insert a new row.
INSERT INTO dbo.doc_exy VALUES ('MyNewColumnSize', 99999.9999);
GO
-- Verify the current column size.
SELECT name,
TYPE_NAME(system_type_id),
max_length,
precision,
scale
FROM sys.columns
WHERE object_id = OBJECT_ID(N'dbo.doc_exy');
C. 열 데이터 정렬 변경
다음 예에서는 열의 데이터 정렬을 변경하는 방법을 보여 줍니다. 먼저 기본 사용자 데이터 정렬을 사용하여 테이블을 만듭니다.
CREATE TABLE T3
(
C1 INT PRIMARY KEY,
C2 VARCHAR (50) NULL,
C3 INT NULL,
C4 INT
);
GO
그런 다음 C2
열 데이터 정렬을 Latin1_General_BIN으로 변경합니다. 데이터 형식은 변경하지 않더라도 필요합니다.
ALTER TABLE T3
ALTER COLUMN C2 VARCHAR (50) COLLATE Latin1_General_BIN;
GO
D. 열 암호화
다음 예는 보안 Enclave를 사용한 Always Encrypted를 사용하여 열을 암호화하는 방법을 보여 줍니다.
먼저 암호화된 열이 없는 테이블이 만들어집니다.
CREATE TABLE T3
(
C1 INT PRIMARY KEY,
C2 VARCHAR (50) NULL,
C3 INT NULL,
C4 INT
);
GO
그런 다음, 열 'C2'는 CEK1
이라는 열 암호화 키 및 임의 암호화로 암호화됩니다. 다음 문이 성공하려면:
- 열 암호화 키는 Enclave가 사용 가능해야 합니다. 즉, enclave 계산을 허용하는 CMK(열 마스터 키)로 암호화해야 합니다.
- 대상 SQL Server 인스턴스는 보안 Enclave를 사용한 Always Encrypted를 지원해야 합니다.
- 이 문은 보안 Enclave를 사용한 Always Encrypted에 대한 연결 설정에 대해 발행되어야 하며 지원되는 클라이언트 드라이버를 사용해야 합니다.
- 호출 애플리케이션은 CMK에 대한 액세스 권한이 있어야 합니다.
CEK1
ALTER TABLE T3 ALTER COLUMN C2 VARCHAR (50) ENCRYPTED WITH (
COLUMN_ENCRYPTION_KEY = [CEK1],
ENCRYPTION_TYPE = RANDOMIZED,
ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
) NULL;
GO
테이블 정의 변경
이 섹션의 예에서는 테이블 정의를 변경하는 방법을 보여 줍니다.
A. 압축을 변경하도록 테이블 수정
다음 예에서는 분할되지 않은 테이블의 압축을 변경합니다. 힙 또는 클러스터형 인덱스가 다시 작성됩니다. 테이블이 힙이면 모든 비클러스터형 인덱스가 다시 작성됩니다.
ALTER TABLE T1 REBUILD
WITH (DATA_COMPRESSION = PAGE);
다음 예에서는 분할된 테이블의 압축을 변경합니다.
REBUILD PARTITION = 1
구문은 파티션 번호 1
만 다시 작성합니다.
적용 대상: SQL Server.
ALTER TABLE PartitionTable1 REBUILD PARTITION = 1
WITH (DATA_COMPRESSION = NONE);
GO
다음과 같은 대체 구문을 사용하여 같은 작업을 실행하면 테이블의 모든 파티션이 다시 작성됩니다.
적용 대상: SQL Server.
ALTER TABLE PartitionTable1 REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = PAGE ON PARTITIONS (1));
추가 데이터 압축 예제는 데이터 압축을 참조하세요.
B. 보관 압축을 변경하도록 columnstore 테이블 수정
다음 예에서는 추가 압축 알고리즘을 적용하여 columnstore 테이블 파티션을 보다 더 압축합니다. 이 압축으로 테이블 크기는 보다 작아지지만 스토리지 및 검색에 필요한 시간은 증가합니다. 보관하거나 보다 적은 스토리지가 필요한 기타 상황에서 사용할 수 있으며 저장 및 검색에 더 많은 시간을 이용할 수 있습니다.
적용 대상: SQL Server 2014(12.x) 이상 버전 및 Azure SQL Database.
ALTER TABLE PartitionTable1 REBUILD PARTITION = 1
WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE);
GO
다음 예제에서는 옵션으로 COLUMNSTORE_ARCHIVE
압축된 columnstore 테이블 파티션의 압축을 풉니다. 데이터는 복구될 때 모든 columnstore 테이블에 사용된 columnstore 압축으로 계속 압축됩니다.
적용 대상: SQL Server 2014(12.x) 이상 버전 및 Azure SQL Database.
ALTER TABLE PartitionTable1 REBUILD PARTITION = 1
WITH (DATA_COMPRESSION = COLUMNSTORE);
GO
C. 테이블 간에 파티션 전환
다음 예에서는 분할된 테이블을 만들고 파티션 구성표 myRangePS1
을 데이터베이스에 이미 만들었다고 가정합니다. 그런 다음 분할되지 않은 테이블이 분할된 테이블과 같은 구조로 PARTITION 2
테이블의 PartitionTable
와 같은 파일 그룹에 만들어집니다. 그러면 PARTITION 2
테이블의 PartitionTable
데이터가 NonPartitionTable
테이블로 전환됩니다.
CREATE TABLE PartitionTable
(
col1 INT,
col2 CHAR (10)
) ON myRangePS1 (col1);
GO
CREATE TABLE NonPartitionTable
(
col1 INT,
col2 CHAR (10)
) ON test2fg;
GO
ALTER TABLE PartitionTable SWITCH PARTITION 2 TO NonPartitionTable;
GO
D. 분할된 테이블에서 잠금 에스컬레이션 허용
다음 예에서는 분할된 테이블의 파티션 수준에 대한 잠금 에스컬레이션을 활성화합니다. 테이블이 분할되지 않으면 잠금 에스컬레이션이 수준에서 설정 TABLE
됩니다.
적용 대상: SQL Server 및 Azure SQL Database.
ALTER TABLE dbo.T1 SET (LOCK_ESCALATION = AUTO);
GO
E. 테이블에서 변경 내용 추적 구성
다음 예에서는 Person.Person
테이블에 대해 변경 내용 추적을 사용하도록 설정합니다.
적용 대상: SQL Server 및 Azure SQL Database.
USE AdventureWorks2022;
ALTER TABLE Person.Person ENABLE CHANGE_TRACKING;
다음 예에서는 변경 내용 추적을 활성화하고 변경 중에 업데이트되는 열을 추적하도록 설정합니다.
적용 대상: SQL Server.
USE AdventureWorks2022;
GO
ALTER TABLE Person.Person ENABLE CHANGE_TRACKING
WITH (TRACK_COLUMNS_UPDATED = ON);
다음 예에서는 Person.Person
테이블에 대해 변경 내용 추적을 사용하지 않도록 설정합니다.
적용 대상: SQL Server 및 Azure SQL Database.
USE AdventureWorks2022;
GO
ALTER TABLE Person.Person DISABLE CHANGE_TRACKING;
제약 조건 및 트리거 사용 안 함 및 사용
A. 제약 조건 사용 안 함 및 다시 사용
다음 예에서는 데이터에 허용되는 급여를 제한하는 제약 조건을 비활성화합니다.
NOCHECK CONSTRAINT
에 ALTER TABLE
를 사용하면 제약 조건이 비활성화되어 일반적으로 해당 제약 조건을 위반하는 삽입을 허용합니다.
CHECK CONSTRAINT
는 제약 조건을 재설정합니다.
CREATE TABLE dbo.cnst_example
(
id INT NOT NULL,
name VARCHAR (10) NOT NULL,
salary MONEY NOT NULL
CONSTRAINT salary_cap CHECK (salary < 100000)
);
-- Valid inserts
INSERT INTO dbo.cnst_example VALUES (1, 'Joe Brown', 65000);
INSERT INTO dbo.cnst_example VALUES (2, 'Mary Smith', 75000);
-- This insert violates the constraint.
INSERT INTO dbo.cnst_example VALUES (3, 'Pat Jones', 105000);
-- Disable the constraint and try again.
ALTER TABLE dbo.cnst_example NOCHECK CONSTRAINT salary_cap;
INSERT INTO dbo.cnst_example VALUES (3, 'Pat Jones', 105000);
-- Re-enable the constraint and try another insert; this fails.
ALTER TABLE dbo.cnst_example CHECK CONSTRAINT salary_cap;
INSERT INTO dbo.cnst_example VALUES (4, 'Eric James', 110000);
B. 트리거 사용 안 함 및 다시 사용
다음 예에서는 DISABLE TRIGGER
의 ALTER TABLE
옵션을 사용하여 트리거를 해제하고 일반적으로 트리거를 위반하는 삽입을 허용합니다. 그런 다음 ENABLE TRIGGER
를 사용하여 트리거를 재설정합니다.
CREATE TABLE dbo.trig_example
(
id INT,
name VARCHAR (12),
salary MONEY
);
GO
-- Create the trigger.
CREATE TRIGGER dbo.trig1
ON dbo.trig_example
FOR INSERT
AS IF (SELECT COUNT(*)
FROM INSERTED
WHERE salary > 100000) > 0
BEGIN
PRINT 'TRIG1 Error: you attempted to insert a salary > $100,000';
ROLLBACK;
END
GO
-- Try an insert that violates the trigger.
INSERT INTO dbo.trig_example VALUES (1, 'Pat Smith', 100001);
GO
-- Disable the trigger.
ALTER TABLE dbo.trig_example DISABLE TRIGGER trig1;
GO
-- Try an insert that would typically violate the trigger.
INSERT INTO dbo.trig_example VALUES (2, 'Chuck Jones', 100001);
GO
-- Re-enable the trigger.
ALTER TABLE dbo.trig_example ENABLE TRIGGER trig1;
GO
-- Try an insert that violates the trigger.
INSERT INTO dbo.trig_example VALUES (3, 'Mary Booth', 100001);
GO
온라인 작업
A. 낮은 우선 순위 대기 옵션을 사용한 온라인 인덱스 다시 작성
다음 예에서는 낮은 우선 순위 대기 옵션을 지정하여 온라인 인덱스 다시 작성을 수행하는 방법을 보여 줍니다.
적용 대상: SQL Server 2014(12.x) 이상 버전 및 Azure SQL Database.
ALTER TABLE T1 REBUILD WITH (
PAD_INDEX = ON,
ONLINE = ON (
WAIT_AT_LOW_PRIORITY (MAX_DURATION = 4 MINUTES, ABORT_AFTER_WAIT = BLOCKERS)
)
);
B. 온라인 열 변경
다음 예제에서는 옵션을 사용하여 열 변경 작업을 ONLINE
실행하는 방법을 보여줍니다.
적용 대상: SQL Server 2016(13.x) 이상 버전 및 Azure SQL Database.
CREATE TABLE dbo.doc_exy (column_a INT);
GO
INSERT INTO dbo.doc_exy (column_a) VALUES (10);
GO
ALTER TABLE dbo.doc_exy
ALTER COLUMN column_a DECIMAL (5, 2) WITH (ONLINE = ON);
GO
EXECUTE sp_help doc_exy;
DROP TABLE dbo.doc_exy;
GO
시스템 버전 관리
다음 네 가지 예제는 시스템 버전 관리를 사용하는 구문을 숙지하는 데 도움이 됩니다. 추가 지원은 시스템 버전 임시 테이블 시작을 참조하세요.
적용 대상: SQL Server 2016(13.x) 이상 버전 및 Azure SQL Database.
A. 기존 테이블에 시스템 버전 관리 추가
다음 예는 기존 테이블에 시스템 버전 관리를 추가하고 나중에 기록 테이블을 만드는 방법을 보여줍니다. 이 예에서는 InsurancePolicy
라는 기본 키가 정의된 기존 테이블이 있는 경우를 가정합니다. 시작 및 끝 시간 값은 null이 될 수 없으므로 이 예는 시작 및 끝 시간의 기본값을 사용하여 시스템 버전 관리에 대해 새로 생성된 기간 열을 채웁니다. 이 예제에서는 절을 HIDDEN
사용하여 현재 테이블과 상호 작용하는 기존 애플리케이션에 영향을 주지 않습니다. 또한 SQL Database에서만 사용할 수 있는 것을 사용합니다 HISTORY_RETENTION_PERIOD
.
--Alter non-temporal table to define periods for system versioning
ALTER TABLE InsurancePolicy
ADD ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN
DEFAULT SYSUTCDATETIME() NOT NULL,
ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN
DEFAULT CONVERT (DATETIME2, '9999-12-31 23:59:59.99999999') NOT NULL,
PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo);
--Enable system versioning with 1 year retention for historical data
ALTER TABLE InsurancePolicy SET (
SYSTEM_VERSIONING = ON (
HISTORY_RETENTION_PERIOD=1 YEAR
)
);
B. 시스템 버전 관리를 사용하기 위해 기존 솔루션 마이그레이션
다음 예는 temporal 지원을 모방하기 위해 트리거를 사용하는 솔루션에서 시스템 버전 관리로 마이그레이션하는 방법을 보여줍니다. 이 예제에서는 기존 솔루션에 테이블과 테이블을 사용하는 ProjectTask
기존 솔루션이 있다고 가정합니다 ProjectTaskHistory
. 이 솔루션은 해당 기간에 대한 열 및 열을 사용 Changed Date
하며 Revised Date
, 이러한 기간 열은 datetime2 데이터 형식을 사용하지 않으며 테이블에 기본 키가 정의되어 있다고 ProjectTask
가정합니다.
-- Drop existing trigger
DROP TRIGGER ProjectTask_HistoryTrigger;
-- Adjust the schema for current and history table
-- Change data types for existing period columns
ALTER TABLE ProjectTask ALTER COLUMN [Changed Date] DATETIME2 NOT NULL;
ALTER TABLE ProjectTask ALTER COLUMN [Revised Date] DATETIME2 NOT NULL;
ALTER TABLE ProjectTaskHistory ALTER COLUMN [Changed Date] DATETIME2 NOT NULL;
ALTER TABLE ProjectTaskHistory ALTER COLUMN [Revised Date] DATETIME2 NOT NULL;
-- Add SYSTEM_TIME period and set system versioning with linking two existing tables
-- (a certain set of data checks happen in the background)
ALTER TABLE ProjectTask
ADD PERIOD FOR SYSTEM_TIME ([Changed Date], [Revised Date]);
ALTER TABLE ProjectTask SET (
SYSTEM_VERSIONING = ON (
HISTORY_TABLE=dbo.ProjectTaskHistory, DATA_CONSISTENCY_CHECK=ON
)
);
C. 시스템 버전 관리 사용 안 함 및 다시 사용하도록 설정하여 테이블 스키마 변경
이 예는 Department
테이블에 시스템 버전 관리를 비활성화고 열을 추가하며 시스템 버전 관리를 재활성화하는 방법을 보여줍니다. 테이블 스키마를 수정하려면 시스템 버전 관리를 사용 중지해야 합니다. 테이블 스키마를 업데이트하는 동안 두 테이블이 업데이트되지 않도록 트랜잭션 안에서 다음 단계를 수행하면 시스템 버전 관리를 다시 사용하도록 설정할 때 데이터 일관성 확인을 건너뛰고 성능 이점을 얻는 DBA가 사용하도록 설정됩니다. 통계 생성, 파티션 전환, 하나 또는 두 테이블에 대한 압축 적용 등의 작업을 수행할 때 시스템 버전 관리를 사용 중지하지 않아도 됩니다.
BEGIN TRAN
/* Takes schema lock on both tables */
ALTER TABLE Department
SET (SYSTEM_VERSIONING = OFF) ;
/* expand table schema for temporal table */
ALTER TABLE Department
ADD Col5 int DEFAULT NOT NULL 0 ;
/* Expand table schema for history table */
ALTER TABLE DepartmentHistory
ADD Col5 int DEFAULT NOT NULL 0 ;
/* Re-establish versioning again*/
ALTER TABLE Department
SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE=dbo.DepartmentHistory,
DATA_CONSISTENCY_CHECK = OFF)) ;
COMMIT
D. 시스템 버전 관리 제거
이 예는 Department 테이블에서 시스템 버전 관리를 완전히 제거하고 DepartmentHistory
테이블을 삭제하는 방법을 보여줍니다. 또는 시스템에서 사용하는 기간 열을 삭제하여 시스템 버전 관리 정보를 기록할 수 있습니다. 시스템 버전 관리가 활성화된 동안에는 Department
또는 DepartmentHistory
테이블을 삭제할 수 없습니다.
ALTER TABLE Department
SET (SYSTEM_VERSIONING = OFF);
ALTER TABLE Department
DROP PERIOD FOR SYSTEM_TIME;
DROP TABLE DepartmentHistory;
예: Azure Synapse Analytics 및 분석 플랫폼 시스템(PDW)
다음의 예제 A ~ C는 FactResellerSales
데이터베이스의 테이블을 사용합니다.
A. 테이블이 분할되었는지 확인
다음 쿼리는 FactResellerSales
테이블이 분할된 경우 하나 이상의 행을 반환합니다. 테이블이 분할되지 않은 경우 행이 반환되지 않습니다.
SELECT *
FROM sys.partitions AS p
INNER JOIN sys.tables AS t
ON p.object_id = t.object_id
WHERE p.partition_id IS NOT NULL
AND t.name = 'FactResellerSales';
B. 분할된 테이블의 경계 값 확인
다음 쿼리는 FactResellerSales
테이블의 각 파티션에 대해 경계 값을 반환합니다.
SELECT t.name AS TableName,
i.name AS IndexName,
p.partition_number,
p.partition_id,
i.data_space_id,
f.function_id,
f.type_desc,
r.boundary_id,
r.value AS BoundaryValue
FROM sys.tables AS t
INNER JOIN sys.indexes AS i
ON t.object_id = i.object_id
INNER JOIN sys.partitions AS p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
INNER JOIN sys.partition_schemes AS s
ON i.data_space_id = s.data_space_id
INNER JOIN sys.partition_functions AS f
ON s.function_id = f.function_id
LEFT OUTER JOIN sys.partition_range_values AS r
ON f.function_id = r.function_id
AND r.boundary_id = p.partition_number
WHERE t.name = 'FactResellerSales'
AND i.type <= 1
ORDER BY p.partition_number;
C. 분할된 테이블의 파티션 열 확인
다음 쿼리는 테이블의 분할 열 이름을 반환합니다 FactResellerSales
.
SELECT t.object_id AS Object_ID,
t.name AS TableName,
ic.column_id AS PartitioningColumnID,
c.name AS PartitioningColumnName
FROM sys.tables AS t
INNER JOIN sys.indexes AS i
ON t.object_id = i.object_id
INNER JOIN sys.columns AS c
ON t.object_id = c.object_id
INNER JOIN sys.partition_schemes AS ps
ON ps.data_space_id = i.data_space_id
INNER JOIN sys.index_columns AS ic
ON ic.object_id = i.object_id
AND ic.index_id = i.index_id
AND ic.partition_ordinal > 0
WHERE t.name = 'FactResellerSales'
AND i.type <= 1
AND c.column_id = ic.column_id;
D. 두 파티션 병합
다음 예는 테이블에서 두 파티션을 병합합니다.
Customer
테이블에는 다음 정의가 있습니다.
CREATE TABLE Customer
(
id INT NOT NULL,
lastName VARCHAR (20),
orderCount INT,
orderDate DATE
)
WITH (
DISTRIBUTION = HASH(id),
PARTITION(orderCount RANGE LEFT
FOR VALUES (1, 5, 10, 25, 50, 100)
)
);
다음 명령은 10 및 25개의 파티션 경계를 결합합니다.
ALTER TABLE Customer MERGE RANGE (10);
테이블의 새 DDL은 다음과 같습니다.
CREATE TABLE Customer
(
id INT NOT NULL,
lastName VARCHAR (20),
orderCount INT,
orderDate DATE
)
WITH (
DISTRIBUTION = HASH(id),
PARTITION(orderCount RANGE LEFT
FOR VALUES (1, 5, 25, 50, 100)
)
);
E. 파티션 분할
다음 예는 테이블의 파티션을 분할합니다.
Customer
테이블에는 다음과 같은 DDL이 있습니다.
DROP TABLE Customer;
CREATE TABLE Customer
(
id INT NOT NULL,
lastName VARCHAR (20),
orderCount INT,
orderDate DATE
)
WITH (
DISTRIBUTION = HASH(id),
PARTITION(orderCount RANGE LEFT
FOR VALUES (1, 5, 10, 25, 50, 100)
)
);
다음 명령은 50과 100 사이의 값 75로 새 파티션 경계를 만듭니다.
ALTER TABLE Customer SPLIT RANGE (75);
테이블의 새 DDL은 다음과 같습니다.
CREATE TABLE Customer (
id INT NOT NULL,
lastName VARCHAR(20),
orderCount INT,
orderDate DATE)
WITH DISTRIBUTION = HASH(id),
PARTITION ( orderCount (RANGE LEFT
FOR VALUES (1, 5, 10, 25, 50, 75, 100))) ;
F. SWITCH를 사용하여 파티션을 기록 테이블로 이동
다음 예는 Orders
테이블의 파티션에 있는 데이터를 OrdersHistory
테이블의 파티션으로 이동합니다.
Orders
테이블에는 다음과 같은 DDL이 있습니다.
CREATE TABLE Orders
(
id INT,
city VARCHAR (25),
lastUpdateDate DATE,
orderDate DATE
)
WITH (
DISTRIBUTION = HASH(id),
PARTITION(orderDate RANGE RIGHT
FOR VALUES ('2004-01-01', '2005-01-01', '2006-01-01', '2007-01-01')
)
);
이 예에서는 Orders
테이블에 다음과 같은 파티션이 있습니다. 각 파티션에는 데이터가 포함되어 있습니다.
Partition | 데이터가 있나요? | 경계 범위 |
---|---|---|
1 | Yes | OrderDate < '2004-01-01' |
2 | Yes | '2004-01-01' <= OrderDate < '2005-01-01' |
3 | Yes | '2005-01-01' <= OrderDate< '2006-01-01' |
4 | Yes | '2006-01-01'<= OrderDate < '2007-01-01' |
5 | Yes | '2007-01-01' <= OrderDate |
- 파티션 1(데이터 있음):
OrderDate < '2004-01-01'
- 파티션 2(데이터 있음):
'2004-01-01' <= OrderDate < '2005-01-01'
- 파티션 3(데이터 있음):
'2005-01-01' <= OrderDate< '2006-01-01'
- 파티션 4(데이터 있음):
'2006-01-01'<= OrderDate < '2007-01-01'
- 파티션 5(데이터 있음):
'2007-01-01' <= OrderDate
OrdersHistory
테이블에 Orders
테이블과 열 및 열 이름이 동일한 다음과 같은 DDL이 있습니다. 두 테이블 모두 id
열에서 해시 분산되어 있습니다.
CREATE TABLE OrdersHistory
(
id INT,
city VARCHAR (25),
lastUpdateDate DATE,
orderDate DATE
)
WITH (
DISTRIBUTION = HASH(id),
PARTITION(orderDate RANGE RIGHT
FOR VALUES ('2004-01-01')
)
);
열과 열 이름이 동일해야 하지만 파티션 경계는 동일하지 않아도 됩니다. 이 예에서 OrdersHistory
테이블에는 다음과 같은 두 파티션이 있고 두 파티션 모두 비어 있습니다.
- 파티션 1(데이터 없음):
OrderDate < '2004-01-01'
- 파티션 2(비어 있음):
'2004-01-01' <= OrderDate
이전 두 테이블의 경우 다음 명령은 OrderDate < '2004-01-01'
인 모든 행을 Orders
테이블에서 OrdersHistory
테이블로 이동합니다.
ALTER TABLE Orders SWITCH PARTITION 1 TO OrdersHistory PARTITION 1;
그 결과 Orders
의 첫 번째 파티션은 비어 있고 OrdersHistory
의 첫 번째 파티션에는 데이터가 있습니다. 이제 테이블이 다음과 같이 나타납니다.
Orders
테이블
- 파티션 1(비어 있음):
OrderDate < '2004-01-01'
- 파티션 2(데이터 있음):
'2004-01-01' <= OrderDate < '2005-01-01'
- 파티션 3(데이터 있음):
'2005-01-01' <= OrderDate< '2006-01-01'
- 파티션 4(데이터 있음):
'2006-01-01'<= OrderDate < '2007-01-01'
- 파티션 5(데이터 있음):
'2007-01-01' <= OrderDate
OrdersHistory
테이블
- 파티션 1(데이터 있음):
OrderDate < '2004-01-01'
- 파티션 2(비어 있음):
'2004-01-01' <= OrderDate
테이블을 정리 Orders
하려면 다음과 같이 파티션을 병합하여 빈 파티션을 1
2
제거할 수 있습니다.
ALTER TABLE Orders MERGE RANGE ('2004-01-01');
병합 후에는 Orders
테이블에 다음과 같은 파티션이 포함됩니다.
Orders
테이블
- 파티션 1(데이터 있음):
OrderDate < '2005-01-01'
- 파티션 2(데이터 있음):
'2005-01-01' <= OrderDate< '2006-01-01'
- 파티션 3(데이터 있음):
'2006-01-01'<= OrderDate < '2007-01-01'
- 파티션 4(데이터 있음):
'2007-01-01' <= OrderDate
또 한 해가 지나고 2005년도를 보관할 준비가 된 경우를 가정하겠습니다. 다음과 같이 빈 파티션을 분할하여 OrdersHistory
테이블에서 2005년도에 대한 빈 파티션을 할당할 수 있습니다.
ALTER TABLE OrdersHistory SPLIT RANGE ('2005-01-01');
분할 후에는 OrdersHistory
테이블에 다음과 같은 파티션이 포함됩니다.
OrdersHistory
테이블
- 파티션 1(데이터 있음):
OrderDate < '2004-01-01'
- 파티션 2(비어 있음):
'2004-01-01' < '2005-01-01'
- 파티션 3(비어 있음):
'2005-01-01' <= OrderDate
관련 콘텐츠
- sys.tables
- sp_rename
- sp_help
- EVENTDATA(Transact-SQL)
- CREATE TABLE(Transact-SQL)
- DROP TABLE(Transact-SQL)
- ALTER TABLE column_constraint(Transact-SQL)
- ALTER TABLE column_definition(Transact-SQL)
- ALTER TABLE computed_column_definition(Transact-SQL)
- ALTER TABLE index_option(Transact-SQL)
- ALTER TABLE table_constraint(Transact-SQL)