메모리 내 OLTP에서 초기 영역 설문 조사Survey of Initial Areas in In-Memory OLTP

이 항목 적용 대상: 예SQL Server예Azure SQL 데이터베이스없습니다Azure SQL 데이터 웨어하우스 없습니다 병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL ServeryesAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

이 문서는 Microsoft SQL Server 및 Azure SQL 데이터베이스의 메모리 내 OLTP 성능 기능의 기본 사항을 급히 알아보려는 개발자를 위해 작성되었습니다.This article is for the developer who is in a hurry to learn the basics of the In-Memory OLTP performance features of Microsoft SQL Server and Azure SQL Database.

이 문서에서는 메모리 내 OLTP에 대해 다음 사항을 제공합니다.For In-Memory OLTP, this article provides the following:

  • 기능에 대한 빠른 설명Quick explanations of the features.
  • 기능을 구현하는 핵심 코드 샘플Core code samples that implement the features.

사소한 점을 제외하고 메모리 내 기술 지원과 관련된 SQL Server와 SQL 데이터베이스의 차이는 거의 없습니다.SQL Server and SQL Database have only minor variations in their support of In-Memory technologies.

일부 블로거들은 비공식적으로 메모리 내 OLTP를 Hekaton이라고도 합니다.In the wild some bloggers refer to the In-Memory OLTP as Hekaton.

메모리 내 기능의 이점Benefits of In-Memory Features

SQL Server는 많은 응용 프로그램 시스템의 성능을 크게 향상시킬 수 있는 메모리 내 기능을 제공합니다.SQL Server provides In-Memory features that can greatly improve the performance of many application systems. 이 섹션에서는 가장 명확한 고려 사항에 대해 설명합니다.The most straight forward considerations are described in this section.

OLTP(온라인 트랜잭션 처리) 기능Features for OLTP (Online Transactional Processing)

동시에 다수의 SQL INSERT를 처리해야 하는 시스템이 OLTP 기능에 가장 적합합니다.Systems which must processes large numbers of SQL INSERTs concurrently are excellent candidates for the OLTP features.

  • 벤치마크 결과에 따르면 메모리 내 기능을 도입할 경우 속도가 5배에서 20배까지 향상됩니다.Our benchmarks show that speed improvements from 5 times to 20 times faster are achievable by adoption of the In-Memory features.

Transact-SQL 계산을 많이 처리하는 시스템도 적합합니다.Systems which process heavy calculations in Transact-SQL are excellent candidates.

  • 복잡한 계산 전용의 저장 프로시저는 최대 99배까지 더 빠르게 실행할 수 있습니다.A stored procedure that is dedicated to heavy calculations can run up to 99 times faster.

나중에 메모리 내 OLTP의 성능 향상 데모를 제공하는 다음 문서를 참조하는 것이 좋습니다.Later you might visit the following articles which offer demonstrations of performance gains from In-Memory OLTP:

운영 분석 기능Features for Operational Analytics

메모리 내 분석은 일반적으로 GROUP BY 절을 포함하여 트랜잭션 데이터를 집계하는 SQL SELECT를 가리킵니다.In-Memory Analytics refers to SQL SELECTs which aggregate transactional data, typically by inclusion of a GROUP BY clause. 운영 분석에는 columnstore 라는 인덱스 유형이 중요합니다.The index type called columnstore is central to operational analytics.

다음 두 가지 주요 시나리오가 있습니다.There are two major scenarios:

  • 배치 운영 분석 은 업무 시간 이후 또는 트랜잭션 데이터의 복사본이 있는 보조 하드웨어에서 실행되는 집계 프로세스를 가리킵니다.Batch Operational Analytics refers to aggregation processes that run either after business hours or on secondary hardware which has copies of the transactional data.
  • 실시간 운영 분석 은 업무 시간 중 및 트랜잭션 작업에 사용되는 주 하드웨어에서 실행되는 집계 프로세스를 가리킵니다.Real-time Operational Analytics refers to aggregration processes that run during business hours and on the primary hardware which is used for transactional workloads.

현재 문서에서는 분석이 아닌 OLTP에 중점을 둡니다.The present article focuses on OLTP, and not on Analytics. columnstore 인덱스에서 분석을 SQL로 가져오는 방법에 대한 자세한 내용은 다음을 참조하세요.For information on how columnstore indexes bring Analytics to SQL, see:


메모리 내 기능에 대한 동영상(2분 소요)은 Azure SQL Database - In-Memory Technologies(Azure SQL 데이터베이스 - 메모리 내 기술)에서 확인할 수 있습니다.A two minute video about the In-Memory features is available at Azure SQL Database - In-Memory Technologies. 이 동영상은 2015년 12월에 발표되었습니다.The video is dated December 2015.


일련의 뛰어난 블로그 게시물은 여러 관점에서 columnstore 인덱스에 대해 설명합니다.A sequence of excellent blog posts elegantly explains columnstore indexes from several perspectives. 대부분의 게시물은 columnstore에서 지원하는 실시간 운영 분석의 개념에 대해 추가로 설명합니다.The majority of the posts describe further the concept of real-time operational analytics, which columnstore supports. 이러한 게시물은 2016년 3월 Microsoft의 프로그램 관리자인 Sunil Agarwal이 작성한 것입니다.These posts were authored by Sunil Agarwal, a Program Manager at Microsoft, in March 2016.

실시간 운영 분석Real-time Operational Analytics

  1. 메모리 내 기술을 사용하는 실시간 운영 분석Real-Time Operational Analytics Using In-Memory Technology
  2. 실시간 운영 분석 - NCCI(비클러스터형 columnstore 인덱스) 개요Real-Time Operational Analytics – Overview nonclustered columnstore index (NCCI)
  3. 실시간 운영 분석: SQL Server 2016에서 NCCI(비클러스터형 columnstore 인덱스)를 사용하는 간단한 예제Real-Time Operational Analytics: Simple example using nonclustered clustered columnstore index (NCCI) in SQL Server 2016
  4. 실시간 운영 분석: SQL Server 2016의 DML 작업 및 NCCI(비클러스터형 columnstore 인덱스)Real-Time Operational Analytics: DML operations and nonclustered columnstore index (NCCI) in SQL Server 2016
  5. 실시간 운영 분석: 필터링된 NCCI(비클러스터형 columnstore 인덱스)Real-Time Operational Analytics: Filtered nonclustered columnstore index (NCCI)
  6. 실시간 운영 분석: NCCI(비클러스터형 Columnstore 인덱스)의 압축 지연 옵션Real-Time Operational Analytics: Compression Delay Option for Nonclustered Columnstore Index (NCCI)
  7. 실시간 운영 분석: NCCI의 압축 지연 옵션 및 성능Real-Time Operational Analytics: Compression Delay option with NCCI and the performance
  8. 실시간 운영 분석: 메모리 액세스에 최적화된 테이블 및 Columnstore 인덱스Real-Time Operational Analytics: Memory-Optimized Tables and Columnstore Index

Columnstore 인덱스를 조각 모음합니다.Defragment a columnstore index

  1. REORGANIZE 명령을 사용하여 Columnstore 인덱스 조각 모음Columnstore Index Defragmentation using REORGANIZE Command
  2. REORGANIZE의 Columnstore 인덱스 병합 정책Columnstore Index Merge Policy for REORGANIZE

데이터 대량 가져오기Bulk importation of data

  1. 클러스터형 열 저장소: 대량 로드Clustered Column Store: Bulk Load
  2. 클러스터형 Columnstore 인덱스: 데이터 로드 최적화 – 최소 로깅Clustered Columnstore Index: Data Load Optimizations – Minimal Logging
  3. 클러스터형 columnstore 인덱스: 데이터 로드 최적화 – 병렬로 대량 가져오기Clustered columnstore Index: Data Load Optimization – Parallel Bulk Import

메모리 내 OLTP의 기능Features of In-Memory OLTP

메모리 내 OLTP의 주요 기능을 살펴보겠습니다.Let's look at the main features of In-Memory OLTP.

메모리 액세스에 최적화된 테이블Memory-optimized tables

CREATE TABLE 문에서 T-SQL 키워드 MEMORY_OPTIMIZED는 디스크가 아니라 활성 메모리에 있도록 테이블을 만드는 방법입니다.The T-SQL keyword MEMORY_OPTIMIZED, on the CREATE TABLE statement, is how a table is created to exist in active memory, instead of on disk.

메모리 액세스에 최적화된 테이블 은 활성 메모리에 포함될 뿐 아니라 디스크에도 보조 복사본이 있습니다.A Memory-optimized tables has one representation of itself in active memory, and secondary copy on the disk.

  • 디스크 복사본은 서버 또는 데이터베이스가 종료된 다음 다시 시작한 후 일상적인 복구를 위해 사용됩니다.The disk copy is for routine recovery after a shutdown-then-restart of the server or database. 이 메모리 및 디스크의 중복성은 사용자와 코드에서 완전히 숨겨집니다.This memory-plus-disk duality is completely hidden from you and your code.

고유하게 컴파일된 모듈Natively compiled modules

CREATE PROCEDURE 문에서 T-SQL 키워드 NATIVE_COMPILATION은 네이티브 컴파일된 저장 프로시저를 만드는 방법입니다.The T-SQL keyword NATIVE_COMPILATION, on the CREATE PROCEDURE statement, is how a natively compiled stored procedure is created. 온라인에서 데이터베이스를 순환할 때마다 네이티브 프로시저를 처음 사용할 때 T-SQL 문이 기계어 코드로 컴파일됩니다.The T-SQL statements are compiled to machine code on first use of the native proc each time the database is cycled online. T-SQL 명령이 각 명령의 느린 해석을 더 이상 허용하지 않습니다.The T-SQL instructions no longer endure slow interpretation of every instruction.

  • 네이티브 컴파일 결과를 확인하는 데 해석된 프로시저 기간의 1/100 정도밖에 걸리지 않았습니다.We have seen native compilation result in durations that are 1/100th of the interpreted duration.

네이티브 모듈은 메모리 최적화 테이블만 참조할 수 있으며, 디스크 기반 테이블은 참조할 수 없습니다.A native module can reference memory-optimized tables only, and it cannot reference disk-based tables.

고유하게 컴파일된 모듈에는 다음 세 가지 유형이 있습니다.There are three types of natively compiled modules:

Azure SQL 데이터베이스의 가용성Availability in Azure SQL Database

메모리 내 OLTP 및 Columnstore를 Azure SQL Database에서 사용할 수 있습니다.In-Memory OLTP and Columnstore are available in Azure SQL Database. 자세한 내용은 SQL Database에서 메모리 내 기술을 사용하여 성능 최적화를 참조하세요.For details see Optimize Performance using In-Memory Technologies in SQL Database.

1. 호환성 수준을 130 이상으로 설정1. Ensure compatibility level >= 130

이 섹션의 앞부분에 나오는 번호가 지정된 일련의 섹션에서는 메모리 내 OLTP 기능을 구현하는 데 사용할 수 있는 Transact-SQL 구문을 보여 줍니다.This section begins a sequence of numbered sections that together demonstrate the Transact-SQL syntax you can use to implement In-Memory OLTP features.

먼저 데이터베이스의 호환성 수준을 적어도 130 이상으로 설정하는 것이 중요합니다.First, it is important that your database be set to a compatibility level of at least 130. 다음은 현재 데이터베이스에 설정된 현재 호환성 수준을 보여 주는 T-SQL 코드입니다.Next is the T-SQL code to view the current compatibility level that your current database is set to.

SELECT d.compatibility_level  
    FROM sys.databases as d  
    WHERE d.name = Db_Name();  

다음은 필요할 경우 수준을 업데이트하는 T-SQL 코드입니다.Next is the T-SQL code to update the level, if necessary.


2. SNAPSHOT으로 권한 상승2. Elevate to SNAPSHOT

트랜잭션에 디스크 기반 테이블과 메모리 최적화 테이블이 모두 포함되어 있을 경우 컨테이너 간 트랜잭션이라고 합니다.When a transaction involves both a disk-based table and a memory-optimized table, we call that a cross-container transaction. 이러한 트랜잭션에서 메모리 최적화 트랜잭션 부분은 SNAPSHOT이라고 하는 트랜잭션 격리 수준에서 작동해야 합니다.In such a transaction it is essential that the memory-optimized portion of the transaction operate at the transaction isolation level named SNAPSHOT.

컨테이너 간 트랜잭션에서 메모리 최적화 테이블에 대해 이 수준을 안정적으로 적용하려면 다음 T-SQL을 실행하여 데이터베이스 설정을 변경합니다.To reliably enforce this level for memory-optimized tables in a cross-container transaction, alter your database setting by executing the following T-SQL.


3. 최적화된 FILEGROUP 만들기3. Create an optimized FILEGROUP

Microsoft SQL Server에서 메모리 최적화 테이블을 만들려면 먼저 CONTAINS MEMORY_OPTIMIZED_DATA를 선언하는 FILEGROUP을 만들어야 합니다.On Microsoft SQL Server, before you can create a memory-optimized table you must first create a FILEGROUP that you declare CONTAINS MEMORY_OPTIMIZED_DATA. 이렇게 하면 FILEGROUP이 데이터베이스에 할당됩니다.The FILEGROUP is assigned to your database. 자세한 내용은 다음을 참조하세요.For details see:

Azure SQL Database에서는 이러한 FILEGROUP을 만들 수 없으며, 만들 필요도 없습니다.On Azure SQL Database, you need not and cannot create such a FILEGROUP.

다음 샘플 T-SQL 스크립트는 메모리 내 OLTP에 데이터베이스를 사용하고 모든 권장 설정을 구성합니다.The following sample T-SQL script enables a database for In-Memory OLTP and configures all recommended settings. 이는 SQL Server와 Azure SQL Database 둘 다에서 작동합니다(enable-in-memory-oltp.sql).It works with both SQL Server and Azure SQL Database: enable-in-memory-oltp.sql.

MEMORY_OPTIMIZED_DATA 파일 그룹이 포함된 데이터베이스에는 일부 SQL Server 기능만 지원됩니다.Note that not all SQL Server features are supported for databases with a MEMORY_OPTIMIZED_DATA filegroup. 제한 사항에 대한 자세한 내용은 메모리 내 OLTP에 대한 지원되지 않는 SQL Server 기능을 참조하세요.For details on limitations see: Unsupported SQL Server Features for In-Memory OLTP

4. 메모리 최적화 테이블 만들기4. Create a memory-optimized table

중요한 Transact-SQL 키워드는 MEMORY_OPTIMIZED 키워드입니다.The crucial Transact-SQL keyword is the keyword MEMORY_OPTIMIZED.

CREATE TABLE dbo.SalesOrder  
    SalesOrderId   integer        not null  IDENTITY  
    CustomerId     integer        not null,  
    OrderDate      datetime       not null  

메모리 최적화 테이블에 대한 Transact-SQL INSERT 및 SELECT 문은 일반 테이블의 경우와 동일합니다.Transact-SQL INSERT and SELECT statements against a memory-optimized table are the same as for a regular table.

메모리 액세스에 최적화된 테이블에 대한 ALTER TABLEALTER TABLE for Memory-Optimized tables

ALTER TABLE... ADD/DROP은 메모리 최적화 테이블 또는 인덱스에서 열을 추가하거나 제거할 수 있습니다.ALTER TABLE...ADD/DROP can add or remove a column from a memory-optimized table, or an index.

메모리 최적화 테이블과 인덱스 계획Plan your memory-optimized tables and indexes

5. 네이티브 컴파일 저장 프로시저 만들기(기본 프로시저)5. Create a natively compiled stored procedure (native proc)

중요한 키워드는 NATIVE_COMPILATION입니다.The crucial keyword is NATIVE_COMPILATION.

CREATE PROCEDURE ncspRetrieveLatestSalesOrderIdForCustomerId  
    @_CustomerId   INT  
        LANGUAGE = N'us_english')  

    DECLARE @SalesOrderId int, @OrderDate datetime;  

    SELECT TOP 1  
            @SalesOrderId = s.SalesOrderId,  
            @OrderDate    = s.OrderDate  
        FROM dbo.SalesOrder AS s  
        WHERE s.CustomerId = @_CustomerId  
        ORDER BY s.OrderDate DESC;  

    RETURN @SalesOrderId;  

키워드 SCHEMABINDING은 기본 프로시저가 먼저 삭제되지 않으면 기본 프로시저에서 참조하는 테이블을 삭제할 수 없음을 의미합니다.The keyword SCHEMABINDING means the tables referenced in the native proc cannot be dropped unless the native proc is dropped first. 자세한 내용은 네이티브 컴파일 저장 프로시저 만들기를 참조하세요.For details see Creating Natively Compiled Stored Procedures.

메모리 최적화 테이블에 액세스하기 위해 네이티브 컴파일된 저장 프로시저를 만들 필요가 없습니다.Note that you do not need to create a natively compiled stored procedure to access a memory-optimized table. 기존의 저장 프로시저 및 임시 일괄 처리에서 메모리 최적화 테이블을 참조할 수도 있습니다.You can also reference memory-optimized tables from traditional stored procedures and ad hoc batches.

6. 기본 프로시저 실행6. Execute the native proc

테이블을 두 개의 데이터 행으로 채웁니다.Populate the table with two rows of data.

INSERT into dbo.SalesOrder  
        ( CustomerId, OrderDate )  
        ( 42, '2013-01-13 03:35:59' ),  
        ( 42, '2015-01-15 15:35:59' );  

네이티브 컴파일 저장 프로시저에 대한 EXECUTE 호출이 그 뒤를 따릅니다.An EXECUTE call to the natively compiled stored procedure follows.

DECLARE @LatestSalesOrderId int, @mesg nvarchar(128);  

EXECUTE @LatestSalesOrderId =  
    ncspRetrieveLatestSalesOrderIdForCustomerId 42;  

SET @mesg = CONCAT(@LatestSalesOrderId,  
    ' = Latest SalesOrderId, for CustomerId = ', 42);  
PRINT @mesg;  

-- Here is the actual PRINT output:  
-- 2 = Latest SalesOrderId, for CustomerId = 42  

설명서와 다음 단계에 대한 가이드Guide to the documentation and next steps

앞의 간단한 예제에서는 메모리 내 OLTP의 고급 기능을 학습하기 위한 토대를 제공합니다.The preceding plain examples give you a foundation for learning the more advanced features of In-Memory OLTP. 다음 섹션은 특별히 알고 있어야 할 고려 사항과, 각 사항에 대한 세부 정보를 볼 수 있는 위치에 대한 가이드입니다.The following sections are a guide to the special considerations you might need to know, and to where you can see the details about each.

메모리 내 OLTP 기능이 훨씬 더 빠르게 작동하는 방법How In-Memory OLTP features work so much faster

다음 하위 섹션에서는 향상된 성능 제공을 위해 메모리 내 OLTP 기능이 내부에서 작동하는 방법에 대해 간략하게 설명합니다.The following subsections briefly describe how the In-Memory OLTP features work internally to provide improved performance.

메모리 최적화 테이블의 성능이 향상되는 방법How memory-optimized tables perform faster

이중 특성: 메모리 최적화 테이블은 활성 메모리에서 표현되고, 하드 디스크에도 표현되는 이중 특성이 있습니다.Dual nature: A memory-optimized table has a dual nature: one representation in active memory, and the other on the hard disk. 각 트랜잭션은 테이블의 두 표현 방식으로 모두 커밋됩니다.Each transaction is committed to both representations of the table. 트랜잭션은 그중 더 빠른 활성 메모리 표현에 대해 작동합니다.Transactions operate against the much faster active memory representation. 메모리 액세스에 최적화된 테이블은 디스크와 비교할 때 더 빨라진 활성 메모리 속도를 활용합니다.Memory-optimized tables benefit from the greater speed of active memory versus the disk. 또한 더 빨라진 활성 메모리로 인해 실제로 속도에 최적화된 고급 테이블 구조가 구현됩니다.Further, the greater nimbleness of active memory makes practical a more advanced table structure that is optimized for speed. 고급 구조는 또한 페이징되지 않아 래치 및 스핀 잠금의 오버헤드와 경합을 방지합니다.The advanced structure is also pageless, so it avoids the overhead and contention of latches and spinlocks.

잠금 없음: 메모리 최적화 테이블은 데이터 무결성과 동시성 및 높은 처리량 간 경쟁하는 목표에 최적의 접근 방법을 사용합니다.No locks: The memory-optimized table relies on an optimistic approach to the competing goals of data integrity versus concurrency and high throughput. 트랜잭션 중 테이블은 업데이트된 데이터 행의 어떤 버전에도 잠금을 설정하지 않습니다.During the transaction, the table does not place locks on any version of the updated rows of data. 이렇게 하면 일부 고용량 시스템의 경합을 크게 줄일 수 있습니다.This can greatly reduce contention in some high volume systems.

행 버전: 잠금 대신 메모리 최적화 테이블은 tempdb가 아닌 테이블 자체에 업데이트된 행의 새로운 버전을 추가합니다.Row versions: Instead of locks, the memory-optimized table adds a new version of an updated row in the table itself, not in tempdb. 원래 행은 트랜잭션이 커밋될 때까지 유지됩니다.The original row is kept until after the transaction is committed. 트랜잭션 중 다른 프로세스에서는 원래 버전의 행을 읽을 수 있습니다.During the transaction, other processes can read the original version of the row.

  • 디스크 기반 테이블의 경우 행 버전이 여러 개 만들어 지면 행 버전은 tempdb에 임시로 저장됩니다.When multiple versions of a row are created for a disk-based table, row versions are stored temporarily in tempdb.

적어진 로깅: 업데이트된 행의 이전 버전과 이후 버전은 메모리 최적화 테이블에서 유지됩니다.Less logging: The before and after versions of the updated rows are held in the memory-optimized table. 이러한 행 쌍은 일반적으로 로그 파일에 기록된 정보의 상당 부분을 제공합니다.The pair of rows provides much of the information that is traditionally written to the log file. 이로 인해 시스템에서 기록하는 정보의 양과, 로그에 정보를 기록하는 빈도가 모두 줄어들었습니다.This enables the system to write less information, and less often, to the log. 그럼에도 불구하고 트랜잭션 무결성은 보장됩니다.Yet transactional integrity is ensured.

네이티브 프로시저의 성능이 향상되는 방법How native procs perform faster

일반 해석된 저장 프로시저를 네이티브 컴파일 저장 프로시저로 변환하면 런타임 시 실행하는 명령 수가 크게 줄어듭니다.Converting a regular interpreted stored procedure into a natively compiled stored procedure greatly reduces the number of instructions to execute during run time.

메모리 내 기능의 상충 관계Trade-offs of In-Memory features

전산학에서 일반적인 경우와 마찬가지로 메모리 내 기능을 통해 제공되는 성능 향상은 절충안입니다.As is common in computer science, the performance gains provided by the In-Memory features are a trade-off. 기능이 향상될 수록 기능으로 인한 추가 비용보다 더 가치 있는 혜택이 수반됩니다.The better features bring benefits that are more valuable than the extra costs of the feature. 다음에서 상충 관계에 대한 포괄적인 지침을 확인할 수 있습니다.You can find comprehensive guidance about the trade-offs at:

이 섹션의 나머지 부분에는 몇 가지 주요 계획 및 상충 관계 고려 사항이 나열되어 있습니다.The rest of this section lists some of the major planning and trade-off considerations.

메모리 최적화 테이블의 장단점Trade-offs of memory-optimized tables

메모리 추정: 메모리 최적화 테이블이 사용하는 활성 메모리 양을 추정할 수 있습니다.Estimate memory: You must estimate the amount of active memory that your memory-optimized table will consume. 컴퓨터 시스템은 메모리 최적화 테이블을 호스트하는 데 적합한 메모리 용량을 확보해야 합니다.Your computer system must have adequate memory capacity to host a memory-optimized table. 자세한 내용은 다음을 참조하세요.For details see:

큰 테이블 분할: 많은 활성 메모리에 대한 요구를 충족하는 한 가지 방법은 큰 테이블을 최근 핫 데이터 행을 저장하는 메모리 내 부분과, 콜드 레거시 행(예: 전체가 배송되어 완료된 판매 주문)을 저장하는 디스크 부분으로 분할하는 것입니다.Partition your large table: One way to meet the demand for lots of active memory is to partition your large table into parts in-memory that store hot recent data rows versus other parts on the disk that store cold legacy rows (such as sales orders that have been fully shipped and completed). 이 분할은 디자인 및 구현 단계에서 수동으로 처리됩니다.This partitioning is a manual process of design and implementation. 다음을 참조하십시오.See:

기본 프로시저의 상충 관계Trade-offs of native procs

  • 네이티브 컴파일 저장 프로시저는 디스크 기반 테이블 형식에 액세스할 수 없습니다.A natively compiled stored procedure cannot access a disk-based table. 기본 프로시저는 메모리 최적화 테이블에만 액세스할 수 있습니다.A native proc can access only memory-optimized tables.
  • 서버 또는 데이터베이스가 가장 최근에 온라인 상태로 전환되고 난 후 기본 프로시저가 처음으로 실행될 때 기본 프로시저는 한 번 다시 컴파일해야 합니다.When a native proc runs for its first time after the server or database was most recently brought back online, the native proc must be recompiled one time. 이 작업으로 인해 기본 프로시저 실행이 시작되기 전에 지연이 발생합니다.This causes a delay before the native proc starts to run.

메모리 최적화 테이블에 대한 고급 고려 사항Advanced considerations for memory-optimized tables

메모리 액세스에 최적화된 테이블의 인덱스 는 일부 방식에서 기존 디스크 테이블의 인덱스와 다릅니다.Indexes for Memory-Optimized Tables are different in some ways from indexes on traditional on-disk tables. 해시 인덱스는 메모리 최적화 테이블에서만 사용할 수 있습니다.Hash Indexes are available only on memory-optimized tables.

계획 중인 메모리 최적화 테이블 및 인덱스에 대해 활성 메모리가 충분한지 확인할 계획을 세워야 합니다.You must plan to ensure there will be sufficient active memory for your planned memory-optimized table and its indexes. 다음을 참조하십시오.See:

DURABILITY = SCHEMA_ONLY를 사용하여 메모리 최적화 테이블을 선언할 수 있습니다.A memory-optimized table can be declared with DURABILITY = SCHEMA_ONLY:

  • 이 구문은 데이터베이스가 오프라인 상태가 될 때 메모리 최적화 테이블에서 데이터를 모두 삭제할 것을 시스템에 알려줍니다.This syntax tells the system to discard all data from the memory-optimized table when the database is taken offline. 테이블 정의만 유지됩니다.Only the table definition is persisted.
  • 데이터베이스가 다시 온라인 상태가 되면 메모리 최적화 테이블은 데이터가 없는 활성 메모리로 다시 로드됩니다.When the database is brought back online, the memory-optimized table is loaded back into active memory, empty of data.
  • 수천 개의 행이 관련된 경우 SCHEMA_ONLY 테이블이 tempdb의 #temporary 테이블 보다 더 효율적일 수 있습니다.SCHEMA_ONLY tables can be a superior alternative to #temporary tables in tempdb, when many thousands of rows are involved.

테이블 변수를 메모리 최적화 변수로 선언할 수도 있습니다.Table variables can also be declared as memory-optimized. 다음을 참조하십시오.See:

네이티브 컴파일 모듈에 대한 고급 고려 사항Advanced considerations for natively compiled modules

TRANSACT-SQL을 통해 사용할 수 있는 네이티브 컴파일 모듈 형식은 다음과 같습니다.The types of natively compiled modules available through Transact-SQL are:

고유하게 컴파일된 UDF(사용자 정의 함수)는 해석된 UDF보다 더 빠르게 실행됩니다.A natively compiled user defined function (UDF) runs faster than an interpreted UDF. UDF와 관련해서 고려해야 할 몇 가지 사항은 다음과 같습니다.Here are some things to consider with UDFs:

  • T-SQL SELECT에서 UDF를 사용하는 경우 UDF가 반환된 행마다 한 번씩 항상 호출됩니다.When a T-SQL SELECT uses a UDF, the UDF is always called once per returned row.
    • UDF는 인라인으로 실행되지 않고 대신 항상 호출됩니다.UDFs never run inline, and instead are always called.
    • 컴파일된 차이는 모든 UDF에 내재된 반복 호출의 오버헤드보다 덜 중요합니다.The compiled distinction is less significant than is the overhead of repeated calls that is inherent to all UDFs.
    • 하지만 실용적인 수준에서 UDF 호출의 오버헤드가 허용되는 경우도 많습니다.Still, the overhead of UDF calls is often acceptable at the practical level.

네이티브 UDF의 성능에 대한 테스트 데이터 및 설명은 다음을 참조하세요.For test data and explanation about the performance of native UDFs, see:

메모리 최적화 테이블에 대한 설명서 가이드Documentation guide for memory-optimized tables

메모리 최적화 테이블에 대한 특별 고려 사항을 설명하는 다음과 같은 기타 문서를 참조하세요.Refer to these other articles that discuss special considerations for memory-optimized tables:

기본 프로시저에 대한 설명서 가이드Documentation guide for native procs

다음 문서 및 그 목차에 나오는 하위 문서에서는 네이티브 컴파일 저장 프로시저에 대해 자세히 설명합니다.The following article, and its children articles in the table of contents (TOC), explain the details about natively compiled stored procedures.

메모리 내 OLTP를 사용하여 얻을 수 있는 성능 향상을 보여 주는 코드를 제공하는 문서는 다음과 같습니다.Here are articles that offer code to demonstrate the performance gains you can achieve by using In-Memory OLTP: