Перенос нагрузки только для чтения на вторичную реплику в группе доступности Always OnOffload read-only workload to secondary replica of an Always On availability group

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

Возможности Группы доступности AlwaysOnAlways On availability groups по активному доступу к вторичным репликам включают поддержку доступа только для чтения к одной или нескольким вторичным репликам (доступным для чтения вторичным репликам).The Группы доступности AlwaysOnAlways On availability groups active secondary capabilities include support for read-only access to one or more secondary replicas (readable secondary replicas). Доступная для чтения вторичная реплика может находиться в режиме доступности как с синхронной, так и с асинхронной фиксацией.A readable secondary replica can be in either synchronous-commit availability mode, or asynchronous-commit availability mode. Доступная для чтения вторичная реплика разрешает доступ только для чтения ко всем своим базам данных-получателям.A readable secondary replica allows read-only access to all its secondary databases. Однако доступные для чтения базы данных-получатели не переводятся в режим доступа только для чтения.However, readable secondary databases are not set to read-only. Они являются динамическими.They are dynamic. Определенная база данных-получатель изменяется по мере того, как к ней применяются изменения, вносимые в данные базы данных-источника.A given secondary database changes as changes on the corresponding primary database are applied to the secondary database. Для большинства вторичных реплик данные, в том числе оптимизированные для памяти устойчивые таблицы, вносятся во вторичную базу данных почти в реальном времени.For a typical secondary replica, the data, including durable memory optimized tables, in the secondary databases is in near real time. Более того, полнотекстовые индексы синхронизируются с базами данных-получателями.Furthermore, full-text indexes are synchronized with the secondary databases. Во многих случаях задержка данных между базой данных-источником и соответствующей базой данных-получателем находится в пределах нескольких секунд.In many circumstances, data latency between a primary database and the corresponding secondary database is only a few seconds.

Параметры безопасности, которые встречаются в базах данных-источниках, сохраняются в базах данных-получателях.Security settings that occur in the primary databases are persisted to the secondary databases. К ним относятся пользователи, роли баз данных и роли приложений, а также соответствующие разрешения и прозрачное шифрование данных, если оно включено в базе данных-источнике.This includes users, database roles, and applications roles together with their respective permissions and transparent data encryption (TDE), if enabled on the primary database.

Примечание

Хотя в базы данных-получатели нельзя записывать данные, их можно записывать в базы данных, предназначенные для чтения и записи на экземпляре сервера, содержащем вторичную реплику, в том числе в пользовательские и системные базы данных, например в базу данных tempdb.Though you cannot write data to secondary databases, you can write to read-write databases on the server instance that hosts the secondary replica, including user databases and system databases such as tempdb.

Группы доступности AlwaysOnAlways On availability groups также поддерживает маршрутизацию запросов соединения с намерением чтения к доступной для чтения вторичной реплике (маршрутизация только для чтения).also supports the re-routing of read-intent connection requests to a readable secondary replica (read-only routing). Дополнительные сведения см. в статье Соединение с помощью прослушивателя со вторичной репликой только для чтения (маршрутизация только для чтения).For information about read-only routing, see Using a Listener to Connect to a Read-Only Secondary Replica (Read-Only Routing).

ПреимуществаBenefits

Направление подключений «только для чтения» к доступным для чтения вторичным репликам обладает следующими преимуществами:Directing read-only connections to readable secondary replicas provides the following benefits:

  • Перераспределяет нагрузку, вызываемую некритическими рабочими процессами, с основой реплики, ресурсы которой высвобождаются для критически важных нагрузок.Offloads your secondary read-only workloads from your primary replica, which conserves its resources for your mission critical workloads. Если на систему возлагается рабочая нагрузка критической важности, не терпящая задержек, для нее следует использовать основную реплику.If you have mission critical read-workload or the workload that cannot tolerate latency, you should run it on the primary.

  • Это позволяет повысить окупаемость систем со вторичными репликами, предназначенными только для чтения.Improves your return on investment for the systems that host readable secondary replicas.

Кроме того, доступные для чтения вторичные реплики обеспечивают надежность операций чтения.In addition, readable secondaries provide robust support for read-only operations, as follows:

  • Автоматические временные данные статистики во вторичной базе данных для чтения оптимизируют запросы только на чтение для дисковых таблиц.Automatic temporary statistics on readable secondary database optimize read-only queries on disk-based tables. Для таблиц, оптимизированных для памяти, отсутствующая статистика создается автоматически.For memory-optimized tables, the missing statistics are created automatically. Однако устаревшие статистические данные не обновляются автоматически.However, there is no auto-update of stale statistics. Статистику на первичной реплике будет необходимо обновить вручную.You will need to manually update the statistics on the primary replica. Дополнительные сведения см. в разделе Статистика для баз данных с доступом только для чтениядалее в этой статье.For more information, see Statistics for Read-Only Access Databases, later in this topic.

  • Рабочие нагрузки только на чтение для дисковых таблиц используют систему управления версиями строк для удаления состязаний блокировок в базах данных-получателях.Read-only workloads for disk-based tables use row versioning to remove blocking contention on the secondary databases. Все запросы, выполняемые к базе данных-получателю, автоматически сопоставляются с уровнем транзакций изоляции моментального снимка баз данных, даже если другие уровни изоляции транзакций заданы явно.All queries that run against the secondary databases are automatically mapped to snapshot isolation transaction level, even when other transaction isolation levels are explicitly set. Кроме того, все указания блокировки пропускаются.Also, all locking hints are ignored. Это позволяет исключить конфликт между чтением и записью.This eliminates reader/writer contention.

  • Рабочие нагрузки только на чтение для устойчивых таблиц, оптимизированных для памяти, обращаются к данным точно таким же способом, как и при доступе к базе данных-источнику, используя скомпилированные в собственном коде хранимые процедуры или совместимость SQL с теми же ограничениями уровня изоляции транзакций (см. статью Уровни изоляции в компоненте Database Engine).Read-only workloads for memory-optimized durable tables access the data in exactly the same way it is accessed on the primary database, using native stored procedures or SQL Interoperability with the same transaction isolation level limitations (See Isolation Levels in the Database Engine). Рабочая нагрузка отчетов или запросов только на чтение, выполняющаяся на главной реплике, может быть запущена на вторичной реплике без внесения каких-либо изменений.Reporting workload or read-only queries running on the primary replica can be run on the secondary replica without requiring any changes. Точно так же, рабочая нагрузка отчетов или запросов только на чтение, выполняющаяся на вторичной реплике, может быть запущена на главной реплике без внесения каких-либо изменений.Similarly, a reporting workload or read-only queries running on a secondary replica can be run on the primary replica without requiring any changes. Так же как и для таблиц на диске, все запросы, выполняемые к базе данных-получателю, автоматически сопоставляются с уровнем транзакций изоляции моментального снимка баз данных, даже если другие уровни изоляции транзакций заданы явно.Similar to disk-based tables, all queries that run against the secondary databases are automatically mapped to snapshot isolation transaction level, even when other transaction isolation levels are explicitly set.

  • Операции DML допустимы для табличных переменных как в дисковых, так и в оптимизированных для памяти типах таблиц на вторичной реплике.DML operations are allowed on table variables both for disk-based and memory-optimized table types on the secondary replica.

Предварительные условия для использования группы доступностиPrerequisites for the Availability Group

  • Доступные для чтения вторичные реплики (необходимое условие)Readable secondary replicas (required)

    Администратор базы данных должен настроить одну или несколько реплик, чтобы они, при выполнении во вторичной роли, разрешали либо все подключения (для доступа только для чтения), либо только подключения с намерением чтения данных.The database administrator needs to configure one or more replicas so that, when running under the secondary role, they allow either all connections (just for read-only access) or only read-intent connections.

    Примечание

    Кроме того, администратор базы данных может настроить любую из имеющихся реплик доступности на исключение соединений только для чтения во время работы в первичной роли.Optionally, the database administrator can configure any of the availability replicas to exclude read-only connections when running under the primary role.

    Дополнительные сведения см. в разделе Сведения о доступе клиентского подключения к репликам доступности (SQL Server).For more information, see About Client Connection Access to Availability Replicas (SQL Server).

  • Прослушиватель группы доступностиAvailability group listener

    Для поддержки маршрутизации только для чтения группа доступности должна иметь прослушиватель группы доступности.To support read-only routing, an availability group must possess an availability group listener. Клиент, запрашивающий данные в режиме только для чтения, должен направлять свои запросы к данному прослушивателю, и в строке подключения клиента должно быть задано намерение приложения «только для чтения».The read-only client must direct its connection requests to this listener, and the client's connection string must specify the application intent as "read-only." Это означает, что они должны быть запросами на соединение с правами чтения.That is, they must be read-intent connection requests.

  • Маршрутизация только для чтенияRead only routing

    Маршрутизация только для чтения обозначает возможность SQL Server направлять входящие запросы соединения с намерением только чтения, предназначенные для прослушивателя группы доступности, на имеющуюся и доступную для чтения вторичную реплику.Read-only routing refers to the ability of SQL Server to route incoming read-intent connection requests, that are directed to an availability group listener, to an available readable secondary replica. Необходимые условия для использования маршрутизации только для чтения:The prerequisites for read-only routing are as follows:

    • Для поддержки маршрутизации только для чтения доступная для чтения вторичная реплика должна иметь URL-адрес для маршрутизации только для чтения.To support read-only routing, a readable secondary replica requires a read-only routing URL. Этот URL-адрес задействуется, только если локальная реплика выполняется под вторичной ролью.This URL takes effect only when the local replica is running under the secondary role. URL-адрес маршрутизации только для чтения должен быть указан для каждой реплики отдельно (если для реплики требуется подобная маршрутизация).The read-only routing URL must be specified on a replica-by-replica basis, as needed. Все URL-адреса маршрутизации только для чтения используются для направления запросов на соединение с намерением чтения к определенной доступной для чтения вторичной реплике.Each read-only routing URL is used for routing read-intent connection requests to a specific readable secondary replica. Как правило, каждой доступной для чтения вторичной реплике назначается URL-адрес маршрутизации только для чтения.Typically, every readable secondary replica is assigned a read-only routing URL.

    • Каждая реплика доступности, поддерживающая маршрутизацию только для чтения и при этом являющаяся первичной репликой, требует наличия списка маршрутизации только для чтения.Each availability replica that is to support read-only routing when it is the primary replica requires a read-only routing list. Определенный список маршрутизации только для чтения вступает в силу, только если локальная реплика выполняется под первичной ролью.A given read-only routing list takes effect only when the local replica is running under the primary role. Такой список должен указываться для тех конкретных реплик, для которых он требуется.This list must be specified on a replica-by-replica basis, as needed. Как правило, каждый список маршрутизации только для чтения будет содержать все URL-адреса маршрутизации только для чтения, причем URL-адрес локальной реплики будет идти в конце списка.Typically, each read-only routing list would contain every read-only routing URL, with the URL of the local replica at the end of the list.

      Примечание

      Для запросов на соединение с намерением чтения может выполняться балансировка нагрузки на нескольких репликах.Read-intent connection requests can be load-balanced across replicas. Дополнительные сведения см. в статье Настройка балансировки нагрузки между репликами только для чтения.For more information, see Configure load-balancing across read-only replicas.

    Дополнительные сведения см. в разделе Настройка маршрутизации только для чтения в группе доступности (SQL Server).For more information, see Configure Read-Only Routing for an Availability Group (SQL Server).

Примечание

Сведения о прослушивателях групп доступности и дополнительные сведения о маршрутизации только для чтения см. в разделе Прослушиватели групп доступности, возможность подключения клиентов и отработка отказа приложений (SQL Server).For information about availability group listeners and more information about read-only routing, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

ОграниченияLimitations and Restrictions

Некоторые операции поддерживаются не полностью.Some operations are not fully supported, as follows:

  • Как только будет открыт доступ к доступной для чтения реплике, она может начать принимать подключения к своим базам данных-получателям.As soon as a readable replica is enabled for read, it can start accepting connections to its secondary databases. Однако при наличии любых активных транзакций в базе данных-источнике версии строк не будут полностью доступны в базе данных-получателе.However, if any active transactions exist on a primary database, the row versions will not be fully available on the corresponding secondary database. Любые активные транзакции, существовавшие в первичной реплике, при настройке вторичной реплики должны быть зафиксированы или откачены.Any active transactions that existed on the primary replica when the secondary replica was configured must commit or roll back. До момента завершения этого процесса сопоставление уровней изоляции транзакций в базе данных-получателе — неполное, а запросы временно блокируются.Until this process completes, the transaction isolation level mapping on the secondary database is incomplete and queries are temporarily blocked.

    Предупреждение

    Выполнение длительных транзакций влияет на количество строк, содержащих версии, для дисковых и оптимизированных для памяти таблиц.Running long transactions impacts the number of versioned rows kept, both for disk-based and memory-optimized tables.

  • Несмотря на то, что для таблиц в памяти всегда создаются версии строк, для базы данных-получателя с таблицами, оптимизированными для памяти, запросы блокируются до тех пор, пока не будут завершены все активные транзакции, которые существовали в первичной реплике на момент открытия для чтения вторичной реплики.On a secondary database with memory-optimized tables, even though row versions are always generated for memory-optimized tables, queries are blocked until all active transactions that existed in the primary replica when the secondary replica was enabled for read complete. Это гарантирует, что и дисковые таблицы, и таблицы, оптимизированные для памяти, будут одновременно доступны и для рабочей нагрузки отчетов, и для запросов только на чтение.This ensures that both disk-based and memory-optimized tables are available to the reporting workload and read-only queries at the same time.

  • Изменение режима отслеживания измененных данных не поддерживается во вторичных базах данных, принадлежащих к доступной для чтения вторичной реплике.Change tracking and change data capture are not supported on secondary databases that belong to a readable secondary replica:

    • Отслеживание изменений явно отключено в базах данных-получателях.Change tracking is explicitly disabled on secondary databases.

    • Отслеживание измененных данных нельзя включить только в базе данных-получателе.Change Data Capture cannot be enabled only on a secondary replica database. Отслеживание измененных данных можно включить в базе данных первичной реплики, в случае чего изменения будут считываться из таблиц CDC с использованием функций в базе данных-получателе.Change Data Capture can be enabled on the primary replica database and the changes can be read from the CDC tables using the functions on the secondary replica database.

  • Операции чтения отображаются на уровень транзакций с изоляцией моментальных снимков, поэтому очистка фантомных записей в первичной реплике может быть заблокирована транзакциями в одной или нескольких вторичных репликах.Because read operations are mapped to snapshot isolation transaction level, the cleanup of ghost records on the primary replica can be blocked by transactions on one or more secondary replicas. Задача очистки фантомных записей автоматически очищает фантомные записи дисковых таблиц в основной реплике, когда они более не нужны в любой из вторичных реплик.The ghost record cleanup task will automatically clean up the ghost records for disk-based tables on the primary replica when they are no longer needed by any secondary replica. Этот процесс сходен с другим процессом, когда транзакции запускаются в первичной реплике.This is similar to what is done when you run transaction(s) on the primary replica. В крайних случаях может понадобиться завершить долго выполняющийся запрос на чтение в базе данных-получателе, который блокирует процесс очистки фантомных записей.In the extreme case on the secondary database, you will need to kill a long running read-query that is blocking the ghost cleanup. Обратите внимание, что очистка фантомных записей может блокироваться, если вторичная реплика отключена или если перемещение данных в базе данных-получателе приостановлено.Note, the ghost clean can be blocked if the secondary replica gets disconnected or when data movement is suspended on the secondary database. Это состояние также предотвращает усечение журнала, поэтому, если оно не проходит, рекомендуется удалить эту базу данных-получатель из группы доступности.This state also prevents log truncation, so if this state persists, we recommend that you remove this secondary database from the availability group. С таблицами, оптимизированными для памяти, не возникает проблем, связанных с очисткой фантомных записей, поскольку версии строк хранятся в памяти и не зависят от версий строк в первичной реплике.There is no ghost record cleanup issue with memory-optimized tables because the row versions are kept in memory and are independent of the row versions on the primary replica.

  • Операция DBCC SHRINKFILE на файлах, содержащих дисковые таблицы, может завершиться с ошибкой в первичной реплике, если файл содержит фантомные записи, которые все еще необходимы во вторичной реплике.The DBCC SHRINKFILE operation on files containing disk-based tables might fail on the primary replica if the file contains ghost records that are still needed on a secondary replica.

  • Начиная с версии SQL Server 2014 (12.x)SQL Server 2014 (12.x), доступные для чтения вторичные реплики могут оставаться в сети даже в случае, если первичная реплика должна быть вне сети из-за действий пользователей или ошибки.Beginning in SQL Server 2014 (12.x)SQL Server 2014 (12.x), readable secondary replicas can remain online even when the primary replica is offline due to user action or a failure. Однако в этой ситуации маршрутизация, доступная только для чтения, не работает, так как прослушиватель группы доступности также находится вне сети.However, read-only routing does not work in this situation because the availability group listener is offline as well. Клиенты могут подключаться непосредственно к вторичным репликам, доступным только для чтения, для рабочих нагрузок, доступных только для чтения.Clients must connect directly to the read-only secondary replicas for read-only workloads.

Примечание

При выполнении запроса к динамическому административному представлению sys.dm_db_index_physical_stats на экземпляре сервера, на котором размещена вторичная реплика, может возникнуть критическое препятствие REDO.If you query the sys.dm_db_index_physical_stats dynamic management view on a server instance that is hosting a readable secondary replica, you might encounter a REDO blocking issue. Это связано с тем, что данное динамическое административное представление получает блокировку (IS) в указанной пользовательской таблице либо в представлении, которые могут блокировать запросы посредством потока REDO для монопольной блокировки (X) этой пользовательской таблицы или представления.This is because this dynamic management view acquires an IS lock on the specified user table or view that can block requests by a REDO thread for an X lock on that user table or view.

Вопросы производительностиPerformance Considerations

В этом разделе рассматриваются некоторые соображения в отношении производительности баз данных-получателей с доступом для чтенияThis section discusses several performance considerations for readable secondary databases

В этом разделе.In This Section:

Задержка данныхData Latency

Применение доступа только для чтения ко вторичным репликам полезно, если для нагрузок, связанных с операциями с ними, приемлема некоторая задержка данных.Implementing read-only access to secondary replicas is useful if your read-only workloads can tolerate some data latency. В ситуациях, когда задержка данных неприемлема, рассмотрите возможность выполнения рабочих нагрузок только чтения за счет первичной реплики.In situations where data latency is unacceptable, consider running read-only workloads against the primary replica.

Из основной реплики выполняется отправка журнала изменений в базе данных-источнике на вторичные реплики.The primary replica sends log records of changes on primary database to the secondary replicas. На каждой базе данных-получателе выделенный поток повтора применяет записи журнала.On each secondary database, a dedicated redo thread applies the log records. В базе данных, доступной для чтения, каждое изменение данных не появляется среди результатов запроса до тех пор, пока запись журнала о данном изменении не будет применена к базе данных-получателю, а транзакция не будет зафиксирована в базе данных-источнике.On a read-access secondary database, a given data change does not appear in query results until the log record that contains the change has been applied to the secondary database and the transaction has been committed on primary database.

Это означает, что между первичной и вторичной репликами возникает некоторая задержка, обычно порядка нескольких секунд.This means that there is some latency, usually only a matter of seconds, between the primary and secondary replicas. В нетипичных случаях, например в ситуации, когда проблемы с сетью ухудшают пропускную способность, задержка может стать значительной.In unusual cases, however, for example if network issues reduce throughput, latency can become significant. Задержка увеличивается из-за наличия узких мест в системе ввода-вывода и в результате приостановки движения данных.Latency increases when I/O bottlenecks occur and when data movement is suspended. Для отслеживания приостановок перемещения данных можно использовать Панель управления AlwaysOn или динамическое административное представление sys.dm_hadr_database_replica_states .To monitor suspended data movement, you can use the Always On Dashboard or the sys.dm_hadr_database_replica_states dynamic management view.

Задержка данных для баз данных с таблицами, оптимизированными для памятиData Latency on databases with memory-optimized tables

В SQL Server 2014 (12.x)SQL Server 2014 (12.x) предлагались особые рекомендации, связанные с задержкой данных в активных вторичных репликах (см. статью SQL Server 2014 (12.x)SQL Server 2014 (12.x)Активные вторичные реплики: вторичные реплики для чтения).In SQL Server 2014 (12.x)SQL Server 2014 (12.x) there were special considerations around data latency on active secondaries - see SQL Server 2014 (12.x)SQL Server 2014 (12.x) Active Secondaries: Readable Secondary Replicas. Начиная с SQL Server 2016 (13.x)SQL Server 2016 (13.x) , никаких особых рекомендаций в связи с задержкой данных в таблицах, оптимизированных для памяти, нет.Starting SQL Server 2016 (13.x)SQL Server 2016 (13.x) there are no special considerations around data latency for memory-optimized tables. Ожидаемая задержка данных в таблицах, оптимизированных для памяти, сопоставима с задержкой в таблицах на диске.The expected data latency for memory-optimized tables is comparable to the latency for disk-based tables.

Влияние на рабочую нагрузку только для чтенияRead-Only Workload Impact

При настройке вторичной реплики для доступа только для чтения, нагрузки только для чтения в базах данных-получателях потребляют системные ресурсы, т. е. ресурсы процессора и системы ввода-вывода (для дисковых таблиц), за счет потоков повтора, в особенности, если нагрузка операций чтения дисковых таблиц выполняет большой объем операций ввода-вывода.When you configure a secondary replica for read-only access, your read-only workloads on the secondary databases consume system resources, such as CPU and I/O (for disk-based tables) from redo threads, especially if the read-only workloads on disk-based tables are highly I/O-intensive. При доступе к таблицам, оптимизированным для памяти, дополнительная нагрузка на систему ввода-вывода отсутствует, поскольку все строки находятся в памяти.There is no IO impact when accessing memory-optimized tables because all the rows reside in memory.

Рабочие нагрузки только чтения на вторичных репликах могут также блокировать изменения с помощью языка описания данных (DDL), проводимые через записи журнала.Also, read-only workloads on the secondary replicas can block data definition language (DDL) changes that are applied through log records.

  • Даже несмотря на то, что операции чтения не вызывают совмещаемых блокировок в связи с управлением версиями строк, эти операции вызывают блокировки стабильности схемы (Sch-S), что может приводить к блокировке операций повтора, в которых применяются изменения с помощью DDL.Even though the read operations do not take shared locks because of row versioning, these operations take schema stability (Sch-S) locks, which can block redo operations that are applying DDL changes. Операции DDL включают операции ALTER/DROP для таблиц и представлений, но не для хранимых процедур.DDL operations include ALTER/DROP tables and Views but not DROP or ALTER of stored procedures. Например, рассмотрим случай удаления дисковой или оптимизированной для памяти таблицы на первичной реплике.So for example, if you drop a table disk-based or memory-optimized, on primary. Если поток REDO обрабатывает записи журнала, чтобы удалить таблицу, он должен получить блокировку SCH_M для таблицы и может быть заблокирован запущенным запросом к таблице.When REDO thread processes the log record to drop the table, it must acquire a SCH_M lock on the table and can get blocked by a running query accessing table. Точно так же происходит и в первичной реплике, за исключением того, что удаление таблицы выполняется в составе пользовательского сеанса, а не потоком REDO.This is the same behavior on primary replica except that the drop of the table is done as part of a user session and not REDO thread.

  • Имеются дополнительные блокирующие оптимизированные для памяти таблицы.There is additional blocking Memory-Optimized Tables. Удаление собственной хранимой процедуры может стать причиной блокировки потока REDO при одновременном выполнении собственной хранимой процедуры на вторичной реплике.A drop of native stored procedure can cause REDO thread to block if there is a concurrent execution of the native stored procedure on the secondary replica. Точно так же происходит и в первичной реплике, за исключением того, что удаление хранимой процедуры выполняется в составе пользовательского сеанса, а не потоком REDO.This is the same behavior on the primary replica except that the drop of the stored procedure is done as part of a user session and not REDO thread.

Необходимо учитывать рекомендации по построению запросов и следовать им в работе с базами данных-получателями.Be aware of best practices around building queries, and exercise those best practices in the secondary databases. Например, планируйте долговременные задачи, такие как статистическая обработка данных, на периоды наименьшей активности.For example, schedule long-running queries such as aggregations of data during times of low activity.

Примечание

Если поток повтора блокируется запросами на вторичной реплике, возникает событие XEvent sqlserver.lock_redo_blocked .If a redo thread is blocked by queries on a secondary replica, the sqlserver.lock_redo_blocked XEvent is raised.

ИндексированиеIndexing

Чтобы оптимизировать рабочие нагрузки только чтения в доступных для чтения вторичных репликах, можно создать индексы на таблицах в базах данных-получателях.To optimize read-only workloads on the readable secondary replicas, you may want to create indexes on the tables in the secondary databases. Возможность вносить изменения в схемы или данные баз данных-получателей отсутствует, поэтому следует создать индексы в базах данных-источниках и разрешить перенос изменений в базы данных-получатели с помощью процесса повтора.Because you cannot make schema or data changes on the secondary databases, create indexes in the primary databases and allow the changes to transfer to the secondary database through the redo process.

Для отслеживания действий использования индекса на вторичной реплике можно создавать запросы к столбцам user_seeks, user_scansи user_lookups динамического административного представления sys.dm_db_index_usage_stats .To monitor index usage activity on a secondary replica, query the user_seeks, user_scans, and user_lookups columns of the sys.dm_db_index_usage_stats dynamic management view.

Статистика для баз данных с доступом только для чтенияStatistics for Read-Only Access Databases

Статистика по столбцам таблиц и индексированных представлений используется для оптимизации планов запросов.Statistics on columns of tables and indexed views are used to optimize query plans. Что касается групп доступности, то статистика, создаваемая и поддерживаемая по базам данных-источникам, автоматически сохраняется в базах данных-получателях в ходе применения записей журнала транзакций.For availability groups, statistics that are created and maintained on the primary databases are automatically persisted on the secondary databases as part of applying the transaction log records. Однако рабочая нагрузка только чтения в базах данных-получателях может требовать иной статистики, чем статистика, формируемая в базах данных-источниках.However, the read-only workload on the secondary databases may need different statistics than those that are created on the primary databases. Однако поскольку базы данных-получатели доступны только для чтения, данные статистики в них сохранять нельзя.However, because secondary databases are restricted to read-only access, statistics cannot be created on the secondary databases.

Для решения этой проблемы во вторичной реплике создается и ведется временная статистика для баз данных-получателей в tempdb.To address this problem, the secondary replica creates and maintains temporary statistics for secondary databases in tempdb. Суффикс _readonly_database_statistic добавляется к имени временной статистики. Он позволяет отличить временную статистику от постоянной, которая сохраняется в основной базе данных.The suffix _readonly_database_statistic is appended to the name of temporary statistics to differentiate them from the permanent statistics that are persisted from the primary database.

Только SQL ServerSQL Server может создавать и обновлять временную статистику.Only SQL ServerSQL Server can create and update temporary statistics. Тем не менее можно удалять временную статистику и наблюдать за ее свойствами с помощью тех же средств, которые используются для работы с постоянной статистикой.However, you can delete temporary statistics and monitor their properties using the same tools that you use for permanent statistics:

  • Удаление временной статистики осуществляется с использованием инструкции DROP STATISTICSTransact-SQLTransact-SQL .Delete temporary statistics using the DROP STATISTICSTransact-SQLTransact-SQL statement.

  • Наблюдение за статистикой ведется с помощью представлений каталога sys.stats и sys.stats_columns .Monitor statistics using the sys.stats and sys.stats_columns catalog views. sys_stats включает столбец is_temporaryдля указания того, какая статистика является постоянной, а какая — временной.sys_stats includes a column, is_temporary, to indicate which statistics are permanent and which are temporary.

Не поддерживается автоматическое обновление статистики для таблиц, оптимизированных для памяти, на первичной или вторичной реплике.There is no support for auto-statistics update for memory-optimized tables on the primary or secondary replica. Необходимо контролировать производительность запросов и планов на вторичной реплике и вручную обновить статистику на первичной реплике, когда в этом возникает необходимость.You must monitor query performance and plans on the secondary replica and manually update the statistics on the primary replica when needed. Однако отсутствующая статистика автоматически создается и на первичной и на вторичной реплике.However, the missing statistics are automatically created both on primary and secondary replica.

Дополнительные сведения о статистике SQL Server см. в статье Статистика.For more information about SQL Server statistics, see Statistics.

В этом разделе.In This Section:

Устаревшая постоянная статистика в базах данных-получателяхStale Permanent Statistics on Secondary Databases

SQL ServerSQL Server определяет, когда постоянная статистика базы данных-получателя устаревает.detects when permanent statistics on a secondary database are stale. Однако изменения в постоянную статистику можно внести только через изменения в базе данных-источнике.But changes cannot be made to the permanent statistics except through changes on the primary database. Для обеспечения оптимизации запросов SQL ServerSQL Server создает временную статистику для дисковых таблиц в базе данных-получателе и использует ее, а не устаревшую постоянную статистику.For query optimization, SQL ServerSQL Server creates temporary statistics for disk-based tables on the secondary database and uses these statistics instead of the stale permanent statistics.

После выполнения обновления постоянной статистики в базе данных-источнике, данные этой статистики автоматически переносятся в базу данных-получатель.When the permanent statistics are updated on the primary database, they are automatically persisted to the secondary database. Затем SQL ServerSQL Server использует обновленные постоянные значения статистики, являющиеся более современными, чем значения временной статистики.Then SQL ServerSQL Server uses the updated permanent statistics, which are more current than the temporary statistics.

При отработке отказа группы доступности временная статистика удаляется во всех вторичных репликах.If the availability group fails over, temporary statistics are deleted on all of the secondary replicas.

ОграниченияLimitations and Restrictions

  • Поскольку временная статистика хранится в базе данных tempdb, перезапуск службы SQL ServerSQL Server приведет к удалению всей временной статистики.Because temporary statistics are stored in tempdb, a restart of the SQL ServerSQL Server service causes all temporary statistics to disappear.

  • Суффикс _readonly_database_statistic зарезервирован для статистики, создаваемой SQL ServerSQL Server.The suffix _readonly_database_statistic is reserved for statistics generated by SQL ServerSQL Server. Этот суффикс нельзя использовать при создании статистики в базе данных-источнике.You cannot use this suffix when creating statistics on a primary database. Дополнительные сведения см. в разделе Statistics.For more information, see Statistics.

Доступ к таблицам, оптимизированным для памяти, на вторичной репликеAccessing memory-optimized tables on a Secondary Replica

С таблицами, оптимизированными для памяти, во вторичной реплике используются те же уровни изоляции транзакций, что и в первичной реплике.The transaction isolation levels that can be used with memory-optimized tables on a secondary replica are the same as on the primary replica. Рекомендуется выбрать изоляцию на уровне сеанса READ COMMITTED и установить параметр на уровне базы данных MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT на значение ON.The recommendation is to set the session-level isolation level to READ COMMITTED and set the database-level option MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT to ON. Пример:For example:

ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON  
GO  
SET TRANSACTION ISOLATION LEVEL READ COMMITTED  
GO  
SELECT SUM(UnitPrice*OrderQty)   
FROM Sales.SalesOrderDetail_inmem  
GO  
  

Рекомендации по планированию загрузкиCapacity Planning Considerations

  • В случае если таблицы хранятся на дисках, доступные для чтения вторичные реплики могут потребовать наличия свободного места в базе данных tempdb по двум причинам:In the case of disk-based tables, readable secondary replicas can require space in tempdb for two reasons:

    • Применение уровня изоляции моментальных снимков приводит к копированию версий строк в базу данных tempdb.Snapshot isolation level copies row versions into tempdb.

    • В базе данных tempdbсоздается и ведется временная статистика для баз данных-получателей.Temporary statistics for secondary databases are created and maintained in tempdb. Временная статистика может привести к небольшому увеличению размера базы данных tempdb.The temporary statistics can cause a slight increase in the size of tempdb. Дополнительные сведения см. в пункте Статистика баз данных, предназначенных только для чтениядалее в этом разделе.For more information, see Statistics for Read-Only Access Databases, later in this section.

  • При настройке доступа для чтения для одной или нескольких вторичных реплик база данных-источник добавляет 14 дополнительных байт для удаляемых, изменяемых или вставляемых строк данных для сохранения указателей на версии строк в базах данных-получателях для таблиц на диске.When you configure read-access for one or more secondary replicas, the primary databases add 14 bytes of overhead on deleted, modified, or inserted data rows to store pointers to row versions on the secondary databases for disk-based tables. Эти дополнительные 14 байт переносятся в базы данных-получатели.This 14-byte overhead is carried over to the secondary databases. Так как к строкам данных добавляются 14 байт, может происходить разбиение страниц.As the 14-byte overhead is added to data rows, page splits might occur.

    Данные версий строк не формируются в базах данных-источниках.The row version data is not generated by the primary databases. Вместо этого версии строк создаются базами данных-получателями.Instead, the secondary databases generate the row versions. Тем не менее управление версиями строк увеличивает объем хранения данных как в базах данных-источниках, так и в базах данных-получателях.However, row versioning increases data storage in both the primary and secondary databases.

    Добавление данных управления версиями строк зависит от настройки уровня изоляции моментальных снимков или уровня изоляции моментальных снимков с чтением зафиксированных данных (RCSI) в базе данных-источнике.The addition of the row version data depends on the snapshot isolation or read-committed snapshot isolation (RCSI) level setting on the primary database. В следующей таблице описано поведение управления версиями в базе данных-получателе, доступной для чтения, с различными настройками для таблиц на диске.The table below describes the behavior of versioning on a readable secondary database under different settings for disk based tables.

    Доступна ли для чтения вторичная реплика?Readable secondary replica? Включен ли уровень изоляции моментальных снимков или RCSI?Snapshot isolation or RCSI level enabled? База данных-источникPrimary Database База данных-получательSecondary Database
    нетNo нетNo Отсутствуют версии строки, либо 14-байтовые издержкиNo row versions or 14-byte overhead Отсутствуют версии строки, либо 14-байтовые издержкиNo row versions or 14-byte overhead
    нетNo ДаYes Версии строк и 14 дополнительных байтRow versions and 14-byte overhead Нет версий строк, но есть 14 дополнительных байтNo row versions, but 14-byte overhead
    ДаYes нетNo Нет версий строк, но есть 14 дополнительных байтNo row versions, but 14-byte overhead Версии строк и 14 дополнительных байтRow versions and 14-byte overhead
    ДаYes ДаYes Версии строк и 14 дополнительных байтRow versions and 14-byte overhead Версии строк и 14 дополнительных байтRow versions and 14-byte overhead

Связанные задачиRelated Tasks

См. такжеRelated Content

См. также:See Also

Обзор групп доступности AlwaysOn (SQL Server) Overview of Always On Availability Groups (SQL Server)
Сведения о доступе клиентского подключения к репликам доступности (SQL Server) About Client Connection Access to Availability Replicas (SQL Server)
Прослушиватели групп доступности, возможность подключения клиентов и отработка отказа приложений (SQL Server) Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server)
СтатистикаStatistics