Обзор начальных областей в выполняющейся в памяти OLTPSurvey of Initial Areas in In-Memory OLTP

ОБЛАСТЬ ПРИМЕНЕНИЯ: даSQL Server даБаза данных SQL Azure нетAzure Synapse Analytics (хранилище данных SQL) нетParallel Data WarehouseAPPLIES TO: yesSQL Server yesAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse

Эта статья предназначена для разработчиков, которым нужно быстро изучить основы повышения производительности In-Memory OLTP в базе данных Microsoft SQL Server и Azure SQL.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.

В этой статье рассматриваются следующие аспекты In-Memory 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)

Максимальную пользу функции OLTP принесут системам, которым приходится обрабатывать большие объемы операций SQL INSERT.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.

Увеличение производительности в результате применения In-Memory OLTP демонстрируется в следующих статьях:Later you might visit the following articles which offer demonstrations of performance gains from In-Memory OLTP:

Функции оперативной аналитикиFeatures for Operational Analytics

Модуль аналитики в памяти ссылается на операции SQL SELECT, которые объединяют данные транзакций (обычно за счет добавления предложения GROUP BY).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.
    • К пакетной операционной аналитике относится такжехранилище данных SQL Azure . Azure SQL Data Warehouse also relates to batch operational analytics.
  • Воперационной аналитике в режиме реального времени используются процессы статистической обработки, которые выполняются в рабочее время и на том оборудовании, где обрабатываются транзакции. 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:

Примечание

Двухминутный видеоролик о функциях выполнения в памяти доступен на странице Базы данных SQL Azure — технологии выполнения в памяти.A two minute video about the In-Memory features is available at Azure SQL Database - In-Memory Technologies. Видеоролик выпущен в декабре 2015 г.The video is dated December 2015.

columnstoreColumnstore

Серия отличных публикаций, доступно и изящно разъясняющих принципы работы с индексами 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 г., — Сунил Агарвал (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. Операционная аналитика в реальном времени. Обзор некластеризованного индекса columnstore (NCCI) Real-Time Operational Analytics - Overview nonclustered columnstore index (NCCI)
  3. Операционная аналитика в реальном времени. Простой пример использования некластеризованного индекса columnstore (NCCI) в SQL Server 2016 Real-Time Operational Analytics: Simple example using nonclustered clustered columnstore index (NCCI) in SQL Server 2016
  4. Операционная аналитика в реальном времени. Операции DML и некластеризованный индекс columnstore (NCCI) в SQL Server 2016 Real-Time Operational Analytics: DML operations and nonclustered columnstore index (NCCI) in SQL Server 2016
  5. Операционная аналитика в реальном времени. Некластеризованный индекс columnstore (NCCI) с фильтрацией Real-Time Operational Analytics: Filtered nonclustered columnstore index (NCCI)
  6. Операционная аналитика в реальном времени. Параметр "Задержка сжатия" для некластеризованного индекса columnstore (NCCI) 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

Дефрагментация индекса columnstoreDefragment a columnstore index

  1. Дефрагментация индекса columnstore с помощью команды REORGANIZE Columnstore Index Defragmentation using REORGANIZE Command
  2. Политика слияния индекса columnstore для команды REORGANIZE Columnstore Index Merge Policy for REORGANIZE

Массовый импорт данныхBulk importation of data

  1. Кластеризованный индекс columnstore. Массовая загрузка 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

Функции выполняемой в памяти OLTPFeatures 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:

  • Скомпилированные в собственном коде хранимые процедуры.Natively compiled stored procedures.
  • Скомпилированные в собственном коде определяемые пользователем функции (UDF), которые являются скалярными.Natively compiled user-defined functions (UDFs), which are scalar.
  • Скомпилированные в собственном коде триггеры.Natively compiled triggers.

Доступность базы данных Azure SQLAvailability in Azure SQL Database

Выполняющаяся в памяти OLTP и индекс columnstore доступны в Базе данных SQL Azure.In-Memory OLTP and Columnstore are available in Azure SQL Database. Дополнительные сведения см. в статье Приступая к работе с In-Memory (в режиме предварительной версии) в базе данных SQL.For details see Optimize Performance using In-Memory Technologies in SQL Database.

1. Обеспечение уровня совместимости не менее 1301. Ensure compatibility level >= 130

Данный раздел начинается с ряда нумерованных разделов, которые демонстрируют синтаксис Transact-SQL, который можно использовать для реализации функций выполнения OLTP в памяти.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.

ALTER DATABASE CURRENT
    SET COMPATIBILITY_LEVEL = 130;

2. Повышение до моментального снимка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. В такой транзакции очень важно обеспечить, чтобы оптимизированная для памяти часть транзакции выполнялась на уровне изоляции транзакции, который называется "моментальный снимок".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.

ALTER DATABASE CURRENT
    SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;

3. Создание оптимизированной файловой группы3. Create an optimized FILEGROUP

В Microsoft SQL Server прежде чем создать таблицу, оптимизированную для памяти, необходимо сначала создать файловую группу, для которой сделано объявление CONTAINS MEMORY_OPTIMIZED_DATA.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. Файловая группа назначается вашей базе данных.The FILEGROUP is assigned to your database. Дополнительные сведения см. в разделе:For details see:

В базе данных SQL Azure не требуется и нет возможности создавать такую файловую группу.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, и для Базы данных SQL Azure: 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. Дополнительные сведения об ограничениях см. в следующей статье: Неподдерживаемые функции SQL Server для выполняющейся в памяти OLTPFor 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
            PRIMARY KEY NONCLUSTERED,
        CustomerId   integer    not null,
        OrderDate    datetime   not null
    )
        WITH
            (MEMORY_OPTIMIZED = ON,
            DURABILITY = SCHEMA_AND_DATA);

Инструкции Transact-SQL INSERT и SELECT для таблицы, оптимизированной для памяти, такие же, как для обычной таблицы.Transact-SQL INSERT and SELECT statements against a memory-optimized table are the same as for a regular table.

Инструкция ALTER TABLE для таблиц, оптимизированных для памятиALTER 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.

  • Инструкции DROP INDEX и CREATE INDEX не могут выполняться для таблиц, оптимизированных для памяти. Вместо них можно использовать ALTER TABLE... и ADD/DROP INDEX.CREATE INDEX and DROP INDEX cannot be run against a memory-optimized table, use ALTER TABLE ... ADD/DROP INDEX instead.
  • Дополнительные сведения см. в разделе Изменение таблиц с оптимизацией для памяти.For details see Altering Memory-Optimized Tables.

Планирование оптимизированных для памяти таблиц и индексов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  
        WITH  
            NATIVE_COMPILATION,  
            SCHEMABINDING  
    AS  
    BEGIN ATOMIC  
        WITH  
            (TRANSACTION ISOLATION LEVEL = SNAPSHOT,
            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;  
    END;  

Ключевое слово 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 )  
    VALUES  
        ( 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 могут служить альтернативой таблицам #temporary в базе данных tempdb.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:

Скомпилированная определяемая пользователем функция выполняется быстрее, чем интерпретированная определяемая пользователем функция.A natively compiled user defined function (UDF) runs faster than an interpreted UDF. При работе с определяемыми пользователем функциями необходимо учитывать следующее:Here are some things to consider with UDFs:

  • Если инструкция T-SQL SELECT использует определяемую пользователем функцию, эта функция всегда вызывается один раз для каждой возвращаемой строки.When a T-SQL SELECT uses a UDF, the UDF is always called once per returned row.
    • Определяемые пользователем функции никогда не запускаются как встроенные, они всегда вызываются.UDFs never run inline, and instead are always called.
    • Разница между этими вариантами менее важна, чем издержки, связанные с повторяющимися вызовами, присущие всем пользовательским функциям.The compiled distinction is less significant than is the overhead of repeated calls that is inherent to all UDFs.
    • Затраты на вызовы определяемых пользователем функций часто допустимы на практике.Still, the overhead of UDF calls is often acceptable at the practical level.

Данные тестов и сведения о производительности определяемых пользователем функций в собственном коде см. в следующих статьях: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.

Следующие статьи содержат примеры кода и демонстрируют повышение производительности за счет применения In-Memory OLTP:Here are articles that offer code to demonstrate the performance gains you can achieve by using In-Memory OLTP: