On sql: Основные команды SQL, которые должен знать каждый программист

Что такое группа доступности Always On? — SQL Server Always On

• 04/29/2020
• Чтение занимает 14 мин

В этой статье

Применимо к:Applies to: SQL ServerSQL Server (все поддерживаемые версии) SQL ServerSQL Server (all supported versions) Применимо к:Applies to: SQL ServerSQL Server (все поддерживаемые версии) SQL ServerSQL Server (all supported versions)

В этом разделе рассматриваются основные понятия Группы доступности AlwaysOnAlways On availability groups , которые имеют большое значение для настройки групп доступности и управления группами доступности в среде SQL ServerSQL Server.This topic introduces the Группы доступности AlwaysOnAlways On availability groups concepts that are central for configuring and managing one or more availability groups in SQL ServerSQL Server. Сводное описание преимуществ групп доступности и общие сведения по терминологии Группы доступности AlwaysOnAlways On availability groups см. в разделе Группы доступности AlwaysOn (SQL Server).For a summary of the benefits offered by availability groups and an overview of Группы доступности AlwaysOnAlways On availability groups terminology, see Always On Availability Groups (SQL Server).

Группа доступности поддерживает реплицированную среду для дискретного набора пользовательских баз данных, известных как базы данных доступности.An availability group supports a replicated environment for a discrete set of user databases, known as availability databases. Можно создать группу доступности для обеспечения высокой доступности (HA) или для чтения и масштабирования.

Каждый набор баз данных доступности размещается с помощью реплики доступности.Each set of availability database is hosted by an availability replica. Существует два типа реплик доступности: одна первичная реплика,Two types of availability replicas exist: a single primary replica. которая размещает основные базы данных, и до восьми вторичных реплик, каждая из которых размещает набор вторичных баз данных и серверов как потенциальных объектов отказа для группы доступности.which hosts the primary databases, and one to eight secondary replicas, each of which hosts a set of secondary databases and serves as a potential failover targets for the availability group. Группа доступности выполняет переход на другой ресурс на уровне реплики доступности.An availability group fails over at the level of an availability replica. Реплика доступности обеспечивает избыточность только на уровне базы данных для набора баз данных из одной группы доступности.

Первичная реплика делает базы данных-источники доступными для соединений с клиентами для чтения и записи.The primary replica makes the primary databases available for read-write connections from clients. первичная реплика отправляет записи журнала транзакций каждой базы данных-источника в каждую базу данных-получатель.The primary replica sends transaction log records of each primary database to every secondary database. Этот процесс, называемый

Также можно настроить одну или несколько вторичных реплик для поддержки доступа только для чтения к базам данных-получателям и настроить какую-либо вторичную реплику для резервного копирования в базы данных-получатели.Optionally, you can configure one or more secondary replicas to support read-only access to secondary databases, and you can configure any secondary replica to permit backups on secondary databases.

В SQL Server 2017 представлены две различные архитектуры для групп доступности.SQL Server 2017 introduces two different architectures for availability groups.

Для развертывания Группы доступности AlwaysOnAlways On availability groups в целях обеспечения высокой доступности в Windows требуется кластер WSFC.Deploying Группы доступности AlwaysOnAlways On availability groups for HA on Windows requires a Windows Server Failover Cluster(WSFC). Все реплики доступности в заданной группе доступности должны располагаться на разных узлах одного кластера WSFC. Each availability replica of a given availability group must reside on a different node of the same WSFC. Единственное исключение состоит в том, что при переносе в другой кластер WSFC группа доступности может временно находится в двух кластерах.The only exception is that while being migrated to another WSFC cluster, an availability group can temporarily straddle two clusters.

В конфигурации с высоким уровнем доступности роль кластера создается для каждой создаваемой группы доступности.In an HA configuration, a cluster role is created for every availability group that you create. Кластер WSFC отслеживает эту роль для оценки работоспособности первичной реплики.The WSFC cluster monitors this role to evaluate the health of the primary replica. Кворум для Группы доступности AlwaysOnAlways On availability groups рассчитывается на всех узлах в кластере WSFC вне зависимости от того, хранится ли на данном узле кластера какая-либо реплика доступности.The quorum for Группы доступности AlwaysOnAlways On availability groups is based on all nodes in the WSFC cluster regardless of whether a given cluster node hosts any availability replicas. В отличие от процесса зеркального отображения базы данных, в Группы доступности AlwaysOnAlways On availability groups нет роли следящего объекта.In contrast to database mirroring, there is no witness role in Группы доступности AlwaysOnAlways On availability groups.

Ниже показана группа доступности, которая содержит одну первичную реплику и четыре вторичные реплики.The following illustration shows an availability group that contains one primary replica and four secondary replicas. Поддерживаются до 8 вторичных реплик, в том числе одна первичная реплика и две вторичные реплики с синхронной фиксацией.Up to eight secondary replicas are supported, including one primary replica and two synchronous-commit secondary replicas.

Базы данных доступностиAvailability databases

Чтобы можно было добавить базу данных в группу доступности, база данных должна быть в сети, быть доступной для чтения и записи и существовать на экземпляре сервера, на котором располагается первичная реплика. To add a database to an availability group, the database must be an online, read-write database that exists on the server instance that hosts the primary replica. При добавлении база данных присоединяется к группе доступности как база данных-источник, оставаясь доступной для клиентов.When you add a database, it joins the availability group as a primary database, while remaining available to clients. База данных-получатель не существует до тех пор, пока резервные копии новой базы данных-источника не будут восстановлены на экземпляр сервера, на котором размещается вторичная реплика (с помощью инструкции RESTORE WITH NORECOVERY).No corresponding secondary database exists until backups of the new primary database are restored to the server instance that hosts the secondary replica (using RESTORE WITH NORECOVERY). Новая база данных-получатель находится в состоянии RESTORING до тех пор, пока не войдет в состав группы доступности.The new secondary database is in the RESTORING state until it is joined to the availability group. Дополнительные сведения см. в статье Запуск перемещения данных для базы данных-получателя AlwaysOn (SQL Server).For more information, see Start Data Movement on an Always On Secondary Database (SQL Server).

Присоединение переводит базу данных-получатель в режим ONLINE и инициирует синхронизацию данных с соответствующей базой данных-источником.Joining places the secondary database into the ONLINE state and initiates data synchronization with the corresponding primary database. Синхронизация данных — это процесс, в ходе которого изменения в базе данных-источнике воспроизводятся в базе данных-получателе.Data synchronization is the process by which changes to a primary database are reproduced on a secondary database. В процессе синхронизации данных база данных-источник отправляет записи журнала транзакций в базу данных-получатель.Data synchronization involves the primary database sending transaction log records to the secondary database.

Важно!

База данных доступности в , Powershell и управляющих объектах SQL Server (SMO) иногда называется репликой базы данных Transact-SQLTransact-SQL.An availability database is sometimes called a database replica in Transact-SQLTransact-SQL, PowerShell, and SQL Server Management Objects (SMO) names. Например, выражение «реплика базы данных» используется в именах динамических представлений управления AlwaysOn, возвращающих сведения о базах данных доступности: sys.dm_hadr_database_replica_states и sys.dm_hadr_database_replica_cluster_states.For example, the term «database replica» is used in the names of the Always On dynamic management views that return information about availability databases: sys.dm_hadr_database_replica_states and sys.dm_hadr_database_replica_cluster_states. Однако в электронной документации по SQL Server термин «реплика» обычно относится к репликам доступности.However, in SQL Server Books Online, the term «replica» typically refers to availability replicas. Например, фразы «первичная реплика» и «вторичная реплика» всегда относятся к репликам доступности.For example, «primary replica» and «secondary replica» always refer to availability replicas.

Реплики доступностиAvailability replicas

Каждая группа доступности определяет набор из двух или более партнеров по обеспечению отработки отказа, известных как реплики доступности.Each availability group defines a set of two or more failover partners known as availability replicas. Реплики доступности являются компонентами группы доступности.Availability replicas are components of the availability group. На каждой реплике доступности размещается копия баз данных доступности в группе доступности.Each availability replica hosts a copy of the availability databases in the availability group. Для данной группы доступности реплики доступности должны находиться на разных экземплярах SQL ServerSQL Server , работающих на разных узлах кластера WSFC. For a given availability group, the availability replicas must be hosted by separate instances of SQL ServerSQL Server residing on different nodes of a WSFC cluster. На каждом из этих экземпляров сервера необходимо включить AlwaysOn.Each of these server instances must be enabled for Always On.

Данный экземпляр может размещать только одну реплику доступности для отдельной группы доступности.A given instance can host only one availability replica per availability group. Однако каждый экземпляр можно использовать на нескольких групп доступности.However, each instance can be used for many availability groups. Данный экземпляр сервера может быть изолированным экземпляром или экземпляром кластера отработки отказа SQL ServerSQL Server .A given instance can be either a stand-alone instance or a SQL ServerSQL Server failover cluster instance (FCI). Если требуется обеспечить избыточность на уровне сервера, используйте экземпляры кластера отработки отказа.If you require server-level redundancy, use Failover Cluster Instances.

Каждая реплика доступности получает роль — первичную роль или вторичную роль, которая наследуется базами данных доступности этой реплики.Every availability replica is assigned an initial role-either the primary role or the secondary role, which is inherited by the availability databases of that replica. Роль данной реплики определяет, размещает ли она базы данных, доступные для чтения и записи, или базы данных только для чтения.The role of a given replica determines whether it hosts read-write databases or read-only databases. Одна реплика, известная как первичная реплика, получает первичную роль и размещает базы данных, доступные для чтения и записи, которые известны как базы данных-получатели.One replica, known as the primary replica, is assigned the primary role and hosts read-write databases, which are known as primary databases. По крайней мере одна из остальных реплик, называемая вторичной репликой, получает вторичную роль. At least one other replica, known as a secondary replica, is assigned the secondary role. Вторичная реплика размещает базы данных только для чтения, называемые базами данных-получателями.A secondary replica hosts read-only databases, known as secondary databases.

Примечание

Если роль реплики доступности не определена, например, во время отработки отказа, ее базы данных временно пребывают в состоянии NOT SYNCHRONIZING.When the role of an availability replica is indeterminate, such as during a failover, its databases are temporarily in a NOT SYNCHRONIZING state. Их роль устанавливается в значение RESOLVING до тех пор, пока роль реплики доступности не будет разрешена.Their role is set to RESOLVING until the role of the availability replica has resolved. Если реплика доступности разрешается в основную роль, ее базы данных становятся базами данных-источниками.If an availability replica resolves to the primary role, its databases become the primary databases. Если реплика доступности разрешается во вторичную роль, ее базы данных становятся базами данных-получателями.If an availability replica resolves to the secondary role, its databases become secondary databases.

Режимы доступностиAvailability modes

Режим доступности — это свойство каждой реплики доступности.The availability mode is a property of each availability replica. Режим доступности определяет, ждет ли первичная реплика перед фиксацией транзакций для базы данных, чтобы данная вторичная реплика записала записи журнала транзакций на диск (записала журнал на диск).The availability mode determines whether the primary replica waits to commit transactions on a database until a given secondary replica has written the transaction log records to disk (hardened the log). Группы доступности AlwaysOnAlways On availability groups поддерживает два режима доступности — режим асинхронной фиксации и режим синхронной фиксации.supports two availability modes-asynchronous-commit mode and synchronous-commit mode.

• Asynchronous-commit modeAsynchronous-commit mode

  Реплика доступности, которая использует этот режим доступности, называется репликой асинхронной фиксации.An availability replica that uses this availability mode is known as an asynchronous-commit replica. В режиме асинхронной фиксации первичная реплика фиксирует транзакции, не ожидая подтверждения того, что вторичная реплика асинхронной фиксации записала журнал на диск.Under asynchronous-commit mode, the primary replica commits transactions without waiting for acknowledgment that an asynchronous-commit secondary replica has hardened the log. Режим асинхронной фиксации минимизирует задержку транзакций в базах данных-получателях, но позволяет им не успевать за базами данных-источниками, что создает риск возможной потери данных.Asynchronous-commit mode minimizes transaction latency on the secondary databases but allows them to lag behind the primary databases, making some data loss possible.

• Synchronous-commit modeSynchronous-commit mode

  Реплика доступности, которая использует этот режим доступности, называется репликой синхронной фиксации.An availability replica that uses this availability mode is known as a synchronous-commit replica. В режиме синхронной фиксации, прежде чем фиксировать транзакции, первичная реплика синхронной фиксации ждет, чтобы вторичная реплика синхронной фиксации подтвердила, что запись журнала на диск завершена.Under synchronous-commit mode, before committing transactions, a synchronous-commit primary replica waits for a synchronous-commit secondary replica to acknowledge that it has finished hardening the log. В режиме синхронной фиксации после синхронизации базы данных-получателя с базой данных-источником зафиксированные транзакции полностью защищены.Synchronous-commit mode ensures that once a given secondary database is synchronized with the primary database, committed transactions are fully protected. Эта защита достигается за счет повышения задержки транзакций.This protection comes at the cost of increased transaction latency.

Дополнительные сведения см. в разделе Режимы доступности (группы доступности AlwaysOn).For more information, see Availability Modes (Always On Availability Groups).

Типы отработки отказаTypes of failover

В рамках контекста сеанса между первичной репликой и вторичной репликой, первичная и вторичная роли становятся потенциально взаимозаменяемыми в процессе, который называется отработка отказа.Within the context of a session between the primary replica and a secondary replica, the primary and secondary roles are potentially interchangeable in a process known as failover. Во время отработки отказа вторичная реплика принимает первичную роль и становится новой первичной репликой.During a failover the target secondary replica transitions to the primary role, becoming the new primary replica. Новая первичная реплика переводит свои базы данных в режим «в сети» в качестве баз данных-источников и выполняет откат всех незафиксированных транзакций.The new primary replica brings its databases online as the primary databases, and client applications can connect to them. Когда прежняя первичная реплика становится доступной, она принимает вторичную роль и становится вторичной репликой.When the former primary replica is available, it transitions to the secondary role, becoming a secondary replica. Прежние базы данных-источники становятся базами данных-получателями, и синхронизация данных возобновляется.The former primary databases become secondary databases and data synchronization resumes.

Существует три вида перехода на другой ресурс: автоматическая отработка отказа, отработка отказа вручную и принудительное обслуживание (с возможной потерей данных).Three forms of failover exist-automatic, manual, and forced (with possible data loss). Форма или формы отработки отказа, поддерживаемые определенной вторичной репликой, зависят от режима доступности и, для режима синхронной фиксации, от режима отработки отказа для первичной реплики и целевой вторичной реплики, как будет показано ниже. The form or forms of failover supported by a given secondary replica depends on its availability mode, and, for synchronous-commit mode, on the failover mode on the primary replica and target secondary replica, as follows.

• Режим синхронной фиксации поддерживает две формы перехода на другой ресурс — запланированный переход на другой ресурс вручную и автоматический переход на другой ресурс, если целевая вторичная реплика синхронизируется с первичной.Synchronous-commit mode supports two forms of failover-planned manual failover and automatic failover, if the target secondary replica is currently synchronized with the primary replica. Поддержка этих форм отработки отказа зависит от свойства режима отработки отказа партнеров по обеспечению отработки отказа.The support for these forms of failover depends on the setting of the failover mode property on the failover partners. Если режим перехода на другой ресурс имеет значение «вручную» для первичной или вторичной реплики, то для этой вторичной реплики поддерживается только режим перехода на другой ресурс «вручную».If failover mode is set to «manual» on either the primary or secondary replica, only manual failover is supported for that secondary replica. Если режим перехода на другой ресурс имеет значение «автоматический» как для первичной, так и для вторичной реплики, то эта вторичная реплика поддерживает как автоматический, так и переход на другой ресурс вручную.If failover mode is set to «automatic» on both the primary and secondary replicas, both automatic and manual failover are supported on that secondary replica.

  • Переход на другой ресурс вручную (без потери данных)Planned manual failover (without data loss)

    Переход на другой ресурс вручную происходит вслед за тем, как администратор баз данных выполняет команду перехода на другой ресурс, после чего синхронизируемая вторичная реплика принимает первичную роль (с гарантированной защитой данных), а первичная реплика — вторичную роль. A manual failover occurs after a database administrator issues a failover command and causes a synchronized secondary replica to transition to the primary role (with guaranteed data protection) and the primary replica to transition to the secondary role. Для перехода на другой ресурс вручную требуется, чтобы первичная реплика и целевая вторичная реплика работали в режиме синхронной фиксации, при этом вторичная реплика уже должна быть синхронизирована.A manual failover requires that both the primary replica and the target secondary replica are running under synchronous-commit mode, and the secondary replica must already be synchronized.

  • Автоматический переход на другой ресурс (без потери данных)Automatic failover (without data loss)

    Автоматический переход на другой ресурс возникает в ответ на сбой, в результате которого синхронизируемая вторичная реплика принимает первичную роль (с гарантированной защитой данных).An automatic failover occurs in response to a failure that causes a synchronized secondary replica to transition to the primary role (with guaranteed data protection). Когда прежняя первичная реплика становится доступной, она принимает вторичную роль.When the former primary replica becomes available, it transitions to the secondary role. Для автоматического перехода на другой ресурс требуется, чтобы первичная реплика и целевая вторичная реплика работали в режиме синхронной фиксации, а режим отработки отказа имел значение «Автоматический».Automatic failover requires that both the primary replica and the target secondary replica are running under synchronous-commit mode with the failover mode set to «Automatic». Помимо этого, вторичная реплика уже должна быть синхронизирована, иметь WSFC-кворум и отвечать условиям, указанным в гибкой политике перехода на другой ресурсдля группы доступности.In addition, the secondary replica must already be synchronized, have WSFC quorum, and meet the conditions specified by the flexible failover policyof the availability group.

    Важно!

    Экземпляры отказоустойчивого кластера SQL Server не поддерживают автоматический переход на другой ресурс с учетом групп доступности, поэтому любая реплика доступности, размещенная в них, должна быть настроена для перехода на другой ресурс вручную.SQL Server Failover Cluster Instances (FCIs) do not support automatic failover by availability groups, so any availability replica that is hosted by an FCI can only be configured for manual failover.

  Примечание

  Заметьте, что если команда принудительной отработки отказа выполняется в синхронизированной вторичной реплике, то она работает так же, как в случае запланированного перехода на другой ресурс вручную.Note that if you issue a forced failover command on a synchronized secondary replica, the secondary replica behaves the same as for a planned manual failover.

• В режиме асинхронной фиксации единственная возможная форма отработки отказа — это принудительный переход на другой ресурс вручную (с возможной потерей данных), который обычно называется принудительная отработка отказа.Under asynchronous-commit mode, the only form of failover is forced manual failover (with possible data loss), typically called forced failover. Принудительная отработка отказа считается формой перехода на другой ресурс вручную, поскольку она может быть инициирована только вручную.Forced failover is considered a form of manual failover because it can only be initiated manually. Принудительная отработка отказа является вариантом аварийного восстановления.Forced failover is a disaster recovery option. Это единственная форма отработки отказа, которая возможна в случае, если целевая вторичная реплика не синхронизирована с первичной репликой.It is the only form of failover that is possible when the target secondary replica is not synchronized with the primary replica.

Дополнительные сведения см. далее в подразделе Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn). For more information, see Failover and Failover Modes (Always On Availability Groups).

Клиентские соединенияClient connections

Можно обеспечить клиентское соединение с первичной репликой данной группы доступности, создав прослушиватель группы доступности.You can provide client connectivity to the primary replica of a given availability group by creating an availability group listener. Прослушиватель группы доступности предоставляет набор ресурсов, который закрепляется за определенной группой доступности и направляет клиентские соединения на соответствующую реплику доступности.An availability group listener provides a set of resources that is attached to a given availability group to direct client connections to the appropriate availability replica.

Прослушиватель группы доступности связан с уникальным DNS-именем, которое является виртуальным сетевым именем (VNN), одним или несколькими виртуальными IP-адресами (VIP) и номером TCP-порта.An availability group listener is associated with a unique DNS name that serves as a virtual network name (VNN), one or more virtual IP addresses (VIPs), and a TCP port number. Дополнительные сведения см. в разделе Прослушиватели групп доступности, возможность подключения клиентов и отработка отказа приложений (SQL Server).For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Совет

Если в группе доступности имеется только две реплики доступности и в ней не разрешен доступ только для чтения к вторичной реплике доступности, клиенты смогут подключаться к первичной реплике доступности с помощью строк подключения к зеркальному отображению базы данных.If an availability group possesses only two availability replicas and is not configured to allow read-access to the secondary replica, clients can connect to the primary replica by using a database mirroring connection string. Этот подход может быть временно полезным после миграции базы данных с зеркального отображения базы данных на сервер Группы доступности AlwaysOnAlways On availability groups. This approach can be useful temporarily after you migrate a database from database mirroring to Группы доступности AlwaysOnAlways On availability groups. Прежде чем добавлять другие вторичные реплики, потребуется создать прослушиватель группы доступности, группу доступности и обновить приложения так, чтобы они использовали сетевое имя прослушивателя.Before you add additional secondary replicas, you will need to create an availability group listener the availability group and update your applications to use the network name of the listener.

Активные вторичные репликиActive secondary replicas

Группы доступности AlwaysOnAlways On availability groups поддерживает активные вторичные реплики.supports active secondary replicas. Активные вторичные функции поддерживают следующее.Active secondary capabilities include support for:

• Проведение операций резервного копирования со вторичными репликами.Performing backup operations on secondary replicas

  Вторичные реплики поддерживают создание резервных копий журнала и резервных копий только для копирования всей базы данных, файлов и файловых групп.The secondary replicas support performing log backups and copy-only backups of a full database, file, or filegroup. Можно настроить группу доступности, указав предпочтение, где следует выполнять резервное копирование.You can configure the availability group to specify a preference for where backups should be performed. Важно понимать, что приоритет не определяется в SQL Server, поэтому не влияет на выполнение нерегламентированного резервного копирования.It is important to understand that the preference is not enforced by SQL Server, so it has no impact on ad-hoc backups. Интерпретация данного приоритета зависит от логики, при ее наличии, которая внесена в задания резервного копирования для каждой из баз данных в указанной группе доступности.The interpretation of this preference depends on the logic, if any, that you script into your back jobs for each of the databases in a given availability group. Для отдельной реплики доступности можно указать приоритет выполнения резервного копирования на данной реплике по отношению к другим репликам из той же группы доступности.For an individual availability replica, you can specify your priority for performing backups on this replica relative to the other replicas in the same availability group. Дополнительные сведения см. в статье Активные вторичные реплики: резервное копирование во вторичных репликах (группы доступности Always On).For more information, see Active Secondaries: Backup on Secondary Replicas (Always On Availability Groups).

• Доступ только для чтения к одной или нескольким вторичным репликам (доступные для чтения вторичные реплики)Read-only access to one or more secondary replicas (readable secondary replicas)

  Любая вторичная реплика доступности может быть настроена на получение доступа только для чтения ко своим локальным базам данных, хотя некоторые операции поддерживаются не полностью.Any secondary availability replica can be configured to allow only read-only access to its local databases, though some operations are not fully supported. Это предотвратит попытки подключения для чтения и записи к вторичной реплике.This will prevent read-write connection attempts to the secondary replica. Кроме того, можно запретить рабочие нагрузки только для чтения на первичной реплике, разрешив доступ только для чтения и записи.It is also possible to prevent read-only workloads on the primary replica by only allowing read-write access. Это предотвратит подключение только для чтения к первичной реплике.This will prevent read-only connections from being made to the primary replica. Дополнительные сведения см. в статье Активные вторичные реплики: вторичные реплики для чтения (группы доступности Always On).For more information, see Active Secondaries: Readable Secondary Replicas (Always On Availability Groups).

  Если в группе доступности имеется прослушиватель группы доступности и одна или несколько доступных для чтения вторичных реплик, то SQL ServerSQL Server может направлять запросы на установку соединения (с целью считывания данных) к одной из них (маршрутизация только для чтения). If an availability group currently possesses an availability group listener and one or more readable secondary replicas, SQL ServerSQL Server can route read-intent connection requests to one of them (read-only routing). Дополнительные сведения см. в разделе Прослушиватели групп доступности, возможность подключения клиентов и отработка отказа приложений (SQL Server).For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Период времени ожидания сеансаSession-timeout period

Период времени ожидания сеанса — это свойство реплики доступности, которое определяет, как долго соединение с другой репликой доступности может оставаться неактивным до закрытия соединения.The session-timeout period is an availability-replica property that determines how long connection with another availability replica can remain inactive before the connection is closed. Первичные и вторичные реплики проверяют связь друг с другом, чтобы подтвердить собственную активность.The primary and secondary replicas ping each other to signal that they are still active. Получение сообщения проверки связи от другой реплики до истечения периода времени ожидания указывает на то, что соединение все еще открыто и экземпляры сервера поддерживают связь.Receiving a ping from the other replica during the timeout period indicates that the connection is still open and that the server instances are communicating. После получения сообщения проверки связи реплика доступности сбрасывает счетчик времени ожидания сеанса для данного соединения.On receiving a ping, an availability replica resets its session-timeout counter on that connection.

Ограничение времени ожидания сеанса исключает неограниченное продолжение работы реплики, ожидающей сообщения проверки связи от другой реплики.The session-timeout period prevents either replica from waiting indefinitely to receive a ping from the other replica. Если в течение периода ожидания от другой реплики не приходит сообщение проверки связи, то реплика прекращает ожидание. Соединение закрывается, и реплика переходит в состояние DISCONNECTED.If no ping is received from the other replica within the session-timeout period, the replica times out. Its connection is closed, and the timed-out replica enters the DISCONNECTED state. Даже если для отключенной реплики настроен режим синхронной фиксации, транзакции не будут ожидать ее повторного подключения и повторной синхронизации.Even if a disconnected replica is configured for synchronous-commit mode, transactions will not wait for that replica to reconnect and resynchronize.

По умолчанию период времени ожидания сеанса каждой реплики доступности составляет 10 секунд.The default session-timeout period for each availability replica is 10 seconds. Это значение задается пользователем и не может быть меньше 5 секунд.This value is user-configurable, with a minimum of 5 seconds. Обычно рекомендуется установить период времени ожидания 10 секунд и более.Generally, we recommend that you keep the time-out period at 10 seconds or greater. При установке значения меньше 10 секунд в сильно загруженной системе возникает вероятность ошибочного сообщения об ошибке.Setting the value to less than 10 seconds creates the possibility of a heavily loaded system declaring a false failure.

Примечание

В роли разрешения период времени ожидания сеанса не применяется, поскольку проверка связи не выполняется.In the resolving role, the session-timeout period does not apply because pinging does not occur.

Автоматическое восстановление страницAutomatic page repair

Каждая реплика доступности пытается автоматически восстановиться с учетом поврежденных страниц в локальной базе данных, разрешая определенные типы ошибок, которые предотвращают чтение страницы данных.Each availability replica tries to automatically recover from corrupted pages on a local database by resolving certain types of errors that prevent reading a data page. Если вторичная реплика не может прочитать страницу, реплика запрашивает свежую копию страницы с первичной реплики. If a secondary replica cannot read a page, the replica requests a fresh copy of the page from the primary replica. Если первичная реплика не может прочесть страницу, реплика направляет запрос получения свежей копии для всех вторичных реплик и получает страницу от первой ответившей реплики.If the primary replica cannot read a page, the replica broadcasts a request for a fresh copy to all the secondary replicas and gets the page from the first to respond. Если этот запрос завершился успешно, то нечитаемая страница заменяется копией, в результате чего ошибка обычно устраняется.If this request succeeds, the unreadable page is replaced by the copy, which usually resolves the error.

Дополнительные сведения см. в статье Автоматическое восстановление страниц (группы доступности: зеркальное отображение баз данных).For more information, see Automatic Page Repair (Availability Groups: Database Mirroring).

Related contentRelated content

См. также:See Also

Режимы доступности (группы доступности AlwaysOn) Availability Modes (Always On Availability Groups)
Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn) Failover and Failover Modes (Always On Availability Groups)
Общие сведения об инструкциях Transact-SQL для групп доступности AlwaysOn (SQL Server) Overview of Transact-SQL Statements for Always On Availability Groups (SQL Server)
Обзор командлетов PowerShell для групп доступности AlwaysOn (SQL Server) Overview of PowerShell Cmdlets for Always On Availability Groups (SQL Server)
Поддержка высокого уровня доступности в базах данных OLTP в памяти High Availability Support for In-Memory OLTP databases
Предварительные требования, ограничения и рекомендации для групп доступности AlwaysOn (SQL Server) Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server)
Создание и настройка групп доступности (SQL Server) Creation and Configuration of Availability Groups (SQL Server)
Активные вторичные реплики: вторичные реплики для чтения (группы доступности Always On) Active Secondaries: Readable Secondary Replicas (Always On Availability Groups)
Активные вторичные реплики: резервное копирование во вторичных репликах (группы доступности Always On) Active Secondaries: Backup on Secondary Replicas (Always On Availability Groups)
Прослушиватели групп доступности, возможность подключения клиентов и отработка отказа приложений (SQL Server)Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server)

Оператор SQL INNER JOIN: синтаксис, примеры

Оператор SQL INNER JOIN формирует таблицу из записей двух или нескольких таблиц. Каждая строка из первой (левой) таблицы, сопоставляется с каждой строкой из второй (правой) таблицы, после чего происходит проверка условия. Если условие истинно, то строки попадают в результирующую таблицу. В результирующей таблице строки формируются конкатенацией строк первой и второй таблиц.

Оператор SQL INNER JOIN имеет следующий синтаксис:

SELECT
    column_names [,... n]
FROM
    Table_1 INNER JOIN Table_2
ON condition

Условие для сравнения задается в операторе ON.

Примеры оператора SQL INNER JOIN. Имеются две таблицы:

Authors — содержит в себе информацию об авторах книг:

Books — содержит в себе информацию о названии книг:

В таблице Books поле BookID являются внешним ключом и ссылаются на таблицу Authors.

Пример 1. Используя оператор SQL INNER JOIN вывести на экран, какими авторами были написаны какие из книг:

SELECT *
FROM Authors INNER JOIN Books
ON Authors.AuthorID = Books.BookID

В данном запросе оператора SQL INNER JOIN условие сравнения — это равенство полей AuthorID и BookID. В результирующую таблицу не попадет книга под названием Programming in Scala, так как значение ее BookID не найдет равенства ни с одной строкой AuthorID.

Результирующая таблица будет выглядеть следующим образом:

Netwrix Data Classification for SQL Server

NEW

Находите и классифицируйте важную для бизнеса информацию. Избегайте ошибок и непостоянства мануальной классификации данных, исправление которых постоянно требовало бы нескольких часов рабочего времени.

NEW

Снизьте количество ложных положительных результатов, используя не только регулярные выражения и ключевые слова, но и статистический анализ.

NEW

Получайте пользу сразу после установки ПО — благодаря преднастроенным правилам классификации для данных, регулируемых GDPR, PCI DSS, HIPAA и другими стандартами вы быстро найдете и сможете защитить эти данные.

NEW

Вы и ваши сотрудники можете самостоятельно создавать и обновлять таксономии, и не придется оплачивать профессиональные услуги каждый раз, когда вам нужно что-то обновить.

NEW

Ваши коллеги смогут легко находить нужную информацию в разных системах, которые подгружают мета-тэги из баз данных. Тэги также помогут улучшить работу других инструментов для защиты данных в БД.

NEW

Пусть ваши коллеги полагаются только на достоверную информацию. При создании нового документа или изменении правил классификации обновленные результаты классификации будут доступны сразу.

NEW

Наши алгоритмы машинного обучения проанализируют набор данных и определят ключевые слова, чтобы классифицировать похожие документы, и вам не придется дополнительно оплачивать профессиональные услуги по настройке правил классификации.

NEW

Пусть правила классификации соответствуют особенностям вашего бизнеса и вашим требованиям. Назначайте веса для каждого ключевого слова, проверяйте результаты классификации и корректируйте значения весов, чтобы получать релевантные результаты.

NEW

Находите информацию, требуемую юридическим отделом, и быстро отвечайте на любые запросы. При этом вам не придется создавать новые правила, и поиск не вызовет сбоев в работе систем.

NEW

Используйте одну платформу для автоматизации поиска и классификации данных на вашем языке и языках ваших иностранных клиентов, партнеров, поставщиков, включая франзузский, греческий, корейский, китайский и японский.

NEW

Снижайте риск сбоев систем и бизнес-процессов. Netwrix Data Classification for SQL Server не использует интрузивные агенты для сбора, анализа, хранения и обновления информации.

listagg in SQL для группировки строк в одну строку

у меня есть таблица 1, показанная ниже

Name  role       F1     status1 status 2 
sam   player     yes      null   null
sam   admin      yes     null    null
sam   guest       no      x       x

я хочу, чтобы результат был

Name  role         status1 status 2 
  sam admin,player    x       x

я сделал запрос к list_agg роли в To one row. but статус null для Сэма, чтобы показать, когда F1=’yes’

запрос, который я использовал

 select name,list_agg(role,',') within group(order by name),max(status1),max(status2)
from table 1 where F1='yes'
group by name 

но я получаю что-то вроде этого

name role          status1   status2 
sam  admin,player     null      null

я хочу, чтобы столбец where работал только на role, а max (status1) был в status1 i.e.’x’.please help me .thank you

SELECT Name,
    LISTAGG(Role, ',') WITHIN GROUP (ORDER BY Role) "Role"
    MAX(CASE WHEN water_access = 'Y' THEN 'Y' ELSE NULL END) "water_access",
    MAX(CASE WHEN food_access = 'Y'  THEN 'Y' ELSE NULL END) "food_access",
    MAX(CASE WHEN power_access = 'Y' THEN 'Y' ELSE NULL END) "power_access"
FROM yourTable
GROUP BY Name
ORDER BY Name DESC

 select * from table_name pivot(sum(name) for role

  ВЫБРАТЬ *
С Фейсбука
ПРИСОЕДИНЯЙТЕСЬ linkedin
НА facebook.name = linkedin.name

ВЫБРАТЬ *
С Фейсбука
ПРИСОЕДИНЯЙТЕСЬ linkedin
ГДЕ facebook.name = linkedin.name

ВЫБРАТЬ *
ИЗ facebook, linkedin
ГДЕ facebook.name = linkedin.name
  

  ВЫБРАТЬ *
ИЗ facebook, linkedin
ГДЕ facebook.name = linkedin.name И (facebook.name = Matt OR linkedin.city = "SF")

ВЫБРАТЬ *
С Фейсбука
ПРИСОЕДИНЯЙТЕСЬ linkedin
НА facebook.name = linkedin.name
ГДЕ facebook.name = Мэтт ИЛИ linkedin.city = "SF"
  

  ВЫБРАТЬ *
ПРИСОЕДИНЯЙТЕСЬ linkedin
На Фейсбуке.name = linkedin.name
ГДЕ facebook.city = 'SF'

ВЫБРАТЬ *
С Фейсбука
ПРИСОЕДИНЯЙТЕСЬ linkedin
НА facebook.name = linkedin.name И facebook.city = 'SF'
  

  ВЫБРАТЬ *
С Фейсбука
LEFT JOIN linkedin
НА facebook.name = linkedin.name
ГДЕ facebook.city = 'SF'
  

  ВЫБРАТЬ *
С Фейсбука
LEFT JOIN linkedin
НА facebook.name = linkedin.name И facebook.city = 'SF'
  

  подарков

1 плюшевый мишка
2 цветы

подарки

1 Алиса
1 Боб

---
ВЫБРАТЬ  *
ОТ подарков г
ВЛЕВО ПРИСОЕДИНИТЬСЯ
        Sengifts SG
НА g.giftID = sg.giftID

---
  

  Мишка Тедди Алиса
Плюшевый мишка Боб
Цветы NULL
  

  Мишка Тедди Алиса
Плюшевый мишка Боб
Цветы NULL
  

  NULL Алиса
NULL Боб
Цветы NULL
  

  ВЫБРАТЬ заголовок, imdb_score
ИЗ фильмов
ПРИСОЕДИНЯЙТЕСЬ к отзывам
НА movies.id = reviews.film_id
ГДЕ title = 'Убить пересмешника';
  

  НА movies.id = reviews.film_id
И <дополнительное условие>
  

  ВЫБРАТЬ заголовок, imdb_score
ИЗ фильмов
ПРИСОЕДИНЯЙТЕСЬ к обзорам фильмов.id = reviews.film_id
ГДЕ title = 'Убить пересмешника';
  

- Первый запрос
ВЫБЕРИТЕ a.actor_id, a.first_name, a.last_name, count (fa.film_id)
ОТ АКТЕРА
ПРИСОЕДИНЯЙТЕСЬ film_actor fa ON a.actor_id = fa.actor_id
ГДЕ fa.film_id <10
ГРУППА ПО a.идентификатор_актера, a.first_name, a.last_name
ORDER BY count (fa.film_id) DESC;
 

ACTOR_ID FIRST_NAME LAST_NAME COUNT
--------------------------------------
108 УОРРЕН НОЛТ 3
162 ОПРА КИЛМЕР 3
19 БОБ ФАВСЕТ 2
10 ХРИСТИАНСКИЙ ДВИГАТЕЛЬ 2
53 ХРАМ МЕНА 2
137 МОРГАН УИЛЬЯМС 1
2 НИК ВАЛЬБЕРГ 1
 

- Второй запрос
Выберите.идентификатор_актера, a.first_name, a.last_name, count (fa.film_id)
ОТ АКТЕРА
ПРИСОЕДИНЯЙТЕСЬ film_actor fa ON a.actor_id = fa.actor_id
  И fa.film_id <10
ГРУППА ПО a.actor_id, a.first_name, a.last_name
ORDER BY count (fa.film_id) DESC;
 

-------------------------------------------------- -------
| Id | Операция | Имя | Ряды |
-------------------------------------------------- -------
| 0 | ВЫБРАТЬ ЗАЯВЛЕНИЕ | | 49 |
| 1 | СОРТИРОВАТЬ ЗАКАЗ ПО | | 49 |
| 2 | ХЭШ ГРУППА ПО | | 49 |
| * 3 | HASH JOIN | | 49 |
| * 4 | ИНДЕКС БЫСТРО ПОЛНОЕ СКАНИРОВАНИЕ | PK_FILM_ACTOR | 49 |
| 5 | ПРОСМОТР | VW_GBF_7 | 200 |
| 6 | ДОСТУП К ТАБЛИЦЕ ПОЛНЫЙ | АКТЕР | 200 |
-------------------------------------------------- -------
 
Информация о предикате (определяется идентификатором операции):
-------------------------------------------------- -
 
   3 - доступ ("ITEM_1" = "FA".«ACTOR_ID»)
   4 - фильтр («FA». «FILM_ID» <10)
 

- Первый запрос
ВЫБЕРИТЕ a.actor_id, a.first_name, a.last_name, count (fa.film_id)
ОТ АКТЕРА
LEFT JOIN film_actor fa ON a.act_id = fa.actor_id
ГДЕ fa.film_id <10
ГРУППА ПО a.actor_id, a.first_name, a.last_name
ORDER BY count (fa.film_id) ASC;
 

ACTOR_ID FIRST_NAME LAST_NAME COUNT
--------------------------------------
194 МЕРИЛ АЛЛЕН 1
198 МЭРИ КЕЙТЕЛЬ 1
30 САНДРА ПЕК 1
85 МИННИ ЗЕЛЛВЕГЕР 1
123 ДЖУЛИАННА ДЕНЧ 1
 

- Второй запрос
ВЫБЕРИТЕ a.actor_id, a.first_name, a.last_name, count (fa.film_id)
ОТ АКТЕРА
LEFT JOIN film_actor fa ON a.actor_id = fa.actor_id
  И fa.film_id <10
ГРУППА ПО a.actor_id, a.first_name, a.last_name
ORDER BY count (fa.film_id) ASC;
 

ACTOR_ID FIRST_NAME LAST_NAME COUNT
-----------------------------------------
3 ED CHASE 0
4 ДЖЕННИФЕР ДЭВИС 0
5 ДЖОННИ ЛОЛЛОБРИГИДА 0
6 БЕТТ НИКОЛСОН 0
...
1 пенелопа гинесс 1
200 ХРАМ ТОРА 1
2 НИК ВАЛЬБЕРГ 1
198 МЭРИ КЕЙТЕЛЬ 1
 

-------------------------------------------------- -------
| Id | Операция | Имя | Ряды |
-------------------------------------------------- -------
| 0 | ВЫБРАТЬ ЗАЯВЛЕНИЕ | | 49 |
| 1 | СОРТИРОВАТЬ ЗАКАЗ ПО | | 49 |
| 2 | ХЭШ ГРУППА ПО | | 49 |
| * 3 | HASH JOIN | | 49 |
| * 4 | ИНДЕКС БЫСТРО ПОЛНОЕ СКАНИРОВАНИЕ | PK_FILM_ACTOR | 49 |
| 5 | ПРОСМОТР | VW_GBF_7 | 200 |
| 6 | ДОСТУП К ТАБЛИЦЕ ПОЛНЫЙ | АКТЕР | 200 |
-------------------------------------------------- -------
 
Информация о предикате (определяется идентификатором операции):
-------------------------------------------------- -
 
   3 - доступ ("ITEM_1" = "FA".«ACTOR_ID»)
   4 - фильтр («FA». «FILM_ID» <10)
 

-------------------------------------------------- -------------
| Id | Операция | Имя | Ряды |
-------------------------------------------------- -------------
| 0 | ВЫБРАТЬ ЗАЯВЛЕНИЕ | | 200 |
| 1 | СОРТИРОВАТЬ ЗАКАЗ ПО | | 200 |
| 2 | MERGE JOIN OUTER | | 200 |
| 3 | ДОСТУП К ТАБЛИЦЕ ПО ИНДЕКСУ ROWID | АКТЕР | 200 |
| 4 | ИНДЕКС ПОЛНОЕ СКАНИРОВАНИЕ | PK_ACTOR | 200 |
| * 5 | СОРТИРОВАТЬ ПРИСОЕДИНИТЬСЯ | | 44 |
| 6 | ПРОСМОТР | VW_GBC_5 | 44 |
| 7 | ХЭШ ГРУППА ПО | | 44 |
| * 8 | ИНДЕКС БЫСТРО ПОЛНОЕ СКАНИРОВАНИЕ | PK_FILM_ACTOR | 49 |
-------------------------------------------------- -------------
 
Информация о предикате (определяется идентификатором операции):
-------------------------------------------------- -
 
   5 - доступ («А»."ACTOR_ID" = "ЭЛЕМЕНТ_1" (+))
       filter ("A". "ACTOR_ID" = "ITEM_1" (+))
   8 - фильтр ("FILM_ID" (+) <10)
 

 ИЗ table1
[ { ВНУТРЕННЕЕ СОЕДИНЕНИЕ
  | LEFT [OUTER] JOIN
  | ПРАВО [ВНЕШНИЙ] ПРИСОЕДИНИТЬСЯ
  | FULL [OUTER] JOIN} table2
НА table1.column1 = table2.column1] 

 ВЫБРАТЬ *
ОТ поставщиков
ГДЕ provider_id <400
ЗАКАЗАТЬ ПО городу DESC; 

 ВЫБРАТЬ продукты.product_name, category.category_name
ИЗ продуктов
Категории INNER JOIN
НА products.category_id = category.category_id
ГДЕ product_name <> 'Груша'; 

 ВЫБЕРИТЕ продукты.имя_продукта, категории.название_категории
ИЗ продуктов
Категории LEFT OUTER JOIN
НА products.category_id = category.category_id
ГДЕ product_name <> 'Груша';