Skip to content

Commit 03af90d

Browse files
committed
Merge branch 'FromPublicRepo' of https://github.com/MicrosoftDocs/sql-docs-pr into 20180601_FromPublicRepo
2 parents 8e3967d + 171626a commit 03af90d

8 files changed

Lines changed: 270 additions & 41 deletions

File tree

docs/advanced-analytics/tutorials/use-python-revoscalepy-to-create-model.md

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -78,7 +78,6 @@ from revoscalepy import RxComputeContext, RxInSqlServer, RxSqlServerData
7878
from revoscalepy import rx_lin_mod, rx_predict, rx_summary
7979
from revoscalepy import RxOptions, rx_import
8080
81-
from pandas import Categorical
8281
import os
8382
8483
def test_linmod_sql():
Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
---
2+
title: Configure a SQL Server Availability Group for read-scale on Windows | Microsoft Docs
3+
description:
4+
author: MikeRayMSFT
5+
ms.author:MikeRay
6+
manager: craigg
7+
ms.reviewer: ""
8+
ms.date: 05/24/2018
9+
ms.topic: conceptual
10+
ms.prod: sql
11+
ms.prod_service: high-availability
12+
ms.reviewer: ""
13+
ms.suite: "sql"
14+
ms.technology: high-availability
15+
ms.tgt_pltfrm: ""
16+
---
17+
# Configure a SQL Server Availability Group for read-scale on Windows
18+
19+
[!INCLUDE[appliesto-ss-xxxx-xxxx-xxx-md](../../../includes/appliesto-ss-xxxx-xxxx-xxx-md.md)]
20+
21+
You can configure a SQL Server Always On Availability Group (AG) for read-scale workloads on Windows. There are two types of architectures for AGs. An architecture for high availability uses a cluster manager to provide improved business continuity and can include readable-secondary replicas. To create this high-availability architecture, see [Creation and Configuration of Availability Groups on Windows](creation-and-configuration-of-availability-groups-sql-server.md). The other architecture supports only read-scale workloads. This article explains how to create an AG without a cluster manager for read-scale workloads. This architecture provides read-scale only. It doesn't provide high availability.
22+
23+
>[!NOTE]
24+
>An availability group with `CLUSTER_TYPE = NONE` can include replicas hosted on different operating system platforms. It cannot support high availability. For Linux operating system see [Configure a SQL Server Availability Group for read-scale on Linux](sql-server-linux-availability-group-configure-rs.md)
25+
26+
[!INCLUDE [Create prerequisites](../includes/ss-availability-group-rs-prereq.md)]
27+
28+
## Create the AG
29+
30+
Create the AG. Set `CLUSTER_TYPE = NONE`. In addition, set each replica with `FAILOVER_MODE = NONE`. Client applications running analytics or reporting workloads can directly connect to the secondary databases. You also can create a read-only routing list. Connections to the primary replica forward read connection requests to each of the secondary replicas from the routing list in a round-robin fashion.
31+
32+
The following Transact-SQL script creates an AG named `ag1`. The script configures the AG replicas with `SEEDING_MODE = AUTOMATIC`. This setting causes SQL Server to automatically create the database on each secondary server after it is added to the AG. Update the following script for your environment. Replace the `<node1>` and `<node2>` values with the names of the SQL Server instances that host the replicas. Replace the `<5022>` value with the port you set for the endpoint. Run the following Transact-SQL script on the primary SQL Server replica:
33+
34+
```sql
35+
CREATE AVAILABILITY GROUP [ag1]
36+
WITH (CLUSTER_TYPE = NONE)
37+
FOR REPLICA ON
38+
N'<node1>' WITH (
39+
ENDPOINT_URL = N'tcp://<node1>:<5022>',
40+
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
41+
FAILOVER_MODE = MANUAL,
42+
SEEDING_MODE = AUTOMATIC,
43+
   SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
44+
),
45+
N'<node2>' WITH (
46+
ENDPOINT_URL = N'tcp://<node2>:<5022>',
47+
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
48+
FAILOVER_MODE = MANUAL,
49+
SEEDING_MODE = AUTOMATIC,
50+
SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
51+
);
52+
53+
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
54+
```
55+
56+
### Join secondary SQL Servers to the AG
57+
58+
The following Transact-SQL script joins a server to an AG named `ag1`. Update the script for your environment. On each secondary SQL Server replica, run the following Transact-SQL script to join the AG:
59+
60+
```sql
61+
ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = NONE);
62+
63+
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
64+
```
65+
66+
[!INCLUDE [Create post](../includes/ss-availability-group-rs-postactivity.md)]
67+
68+
This AG isn't a high-availability configuration. If you need high availability, follow the instructions at [Configure an Always On Availability Group for SQL Server on Linux](sql-server-linux-availability-group-configure-ha.md) or [Creation and Configuration of Availability Groups on Windows](creation-and-configuration-of-availability-groups-sql-server.md).
69+
70+
## Connect to read-only secondary replicas
71+
72+
There are two ways to connect to read-only secondary replicas. Applications can connect directly to the SQL Server instance that hosts the secondary replica and query the databases. They also can use read-only routing, which requires a listener.
73+
74+
* [Readable secondary replicas](../database-engine/availability-groups/windows/active-secondaries-readable-secondary-replicas-always-on-availability-groups.md)
75+
* [Read-only routing](../database-engine/availability-groups/windows/listeners-client-connectivity-application-failover.md#ConnectToSecondary)
76+
77+
## Fail over the primary replica on a read-scale Availability Group
78+
79+
[!INCLUDE[Force failover](../includes/ss-force-failover-read-scale-out.md)]
80+
81+
## Next steps
82+
83+
* [Configure a distributed Availability Group](..\database-engine\availability-groups\windows\distributed-availability-groups-always-on-availability-groups.md)
84+
* [Learn more about availability groups](..\database-engine\availability-groups\windows\overview-of-always-on-availability-groups-sql-server.md)
85+
* [Perform a forced manual failover](../database-engine/availability-groups/windows/perform-a-forced-manual-failover-of-an-availability-group-sql-server.md)

docs/database-engine/availability-groups/windows/read-scale-availability-groups.md

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ ms.suite: "sql"
99
ms.technology: high-availability
1010
ms.tgt_pltfrm: ""
1111
ms.topic: conceptual
12-
ms.assetid:
12+
ms.assetid:
1313
caps.latest.revision: 9
1414
author: MikeRayMSFT
1515
ms.author: mikeray
@@ -18,7 +18,7 @@ manager: craigg
1818
# Read-scale availability groups
1919
[!INCLUDE[appliesto-ss-xxxx-xxxx-xxx-md](../../../includes/appliesto-ss-xxxx-xxxx-xxx-md.md)]
2020

21-
An availability group is a comprehensive solution that brings high-availability capabilities to SQL Server and offers integrated scaling solutions as well. In a typical database application, multiple clients run various types of workloads. Sometimes bottlenecks can develop due to resource constraints. You can free up resources and achieve higher throughput for the OLTP workload. You also can deliver higher performance and scale on read-only workloads. Take advantage of the fastest replication technology for SQL Server and create a group of replicated databases to offload reporting and analytics workloads to read-only replicas.
21+
An availability group is a comprehensive solution that brings high-availability capabilities to SQL Server and offers integrated scaling solutions as well. In a typical database application, multiple clients run various types of workloads. Sometimes bottlenecks can develop due to resource constraints. You can free up resources and achieve higher throughput for the OLTP workload. You also can deliver higher performance and scale on read-only workloads. Take advantage of the fastest replication technology for SQL Server and create a group of replicated databases to offload reporting and analytics workloads to read-only replicas.
2222

2323
With availability groups, one or more secondary replicas can be configured to support read-only access to secondary databases.
2424

@@ -31,7 +31,7 @@ In [!INCLUDE[sssql15-md](../../../includes/sssql15-md.md)] and earlier, all avai
3131
If your business requirement is to conserve resources for mission-critical workloads that run on the primary replica, you can use read-only routing or directly connect to readable secondary replicas. You don't need to depend on integration with any clustering technology. These new capabilities are available for SQL Server 2017 running on both Windows and Linux platforms.
3232

3333
>[!IMPORTANT]
34-
>This is not a high-availability setup. There is no infrastructure to monitor and coordinate failure detection and automatic failover. Without a cluster, SQL Server can't provide the low recovery time objective (RTO) that an automated high-availability solution provides. If you need high-availability capabilities, use a cluster manager (Windows Server failover clustering on Windows or Pacemaker on Linux).
34+
>This is not a high-availability setup. There is no infrastructure to monitor and coordinate failure detection and automatic failover. Without a cluster, SQL Server can't provide the low recovery time objective (RTO) that an automated high-availability solution provides. If you need high-availability capabilities, use a cluster manager (Windows Server failover clustering on Windows or Pacemaker on Linux).
3535
>
3636
>The read-scale availability group can provide disaster recovery capability. When the read-only replicas are in synchronous-commit mode, they provide a recovery point objective (RPO) of zero. To fail over a read-scale availability group, see [Fail over the primary replica on a read-scale availability group](perform-a-planned-manual-failover-of-an-availability-group-sql-server.md#ReadScaleOutOnly).
3737
@@ -44,11 +44,11 @@ A single distributed availability group can have up to 17 readable secondary rep
4444

4545

4646

47-
## Next steps
47+
## Next steps
4848

4949
[Configure a read-scale availability group on Linux](../../../linux/sql-server-linux-availability-group-configure-rs.md)
50+
[Configure a read-scale availability group on Windows](configure-read-scale-availability-groups.md)
5051

51-
## See also
52-
[Overview of AlwaysOn availability groups &#40;SQL Server&#41;](../../../database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.md)
53-
54-
52+
## See also
53+
54+
[Overview of AlwaysOn availability groups &#40;SQL Server&#41;](../../../database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.md)
Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
2+
## Add a database to the availability group
3+
4+
Ensure that the database you add to the availability group is in full recovery mode and has a valid log backup. If this is a test database or a newly created database, take a database backup. On the primary SQL Server, run the following Transact-SQL script to create and back up a database called `db1`:
5+
6+
```sql
7+
CREATE DATABASE [db1];
8+
ALTER DATABASE [db1] SET RECOVERY FULL;
9+
BACKUP DATABASE [db1]
10+
TO DISK = N'/var/opt/mssql/data/db1.bak';
11+
```
12+
13+
On the primary SQL Server replica, run the following Transact-SQL script to add a database called `db1` to an availability group called `ag1`:
14+
15+
```sql
16+
ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];
17+
```
18+
19+
### Verify that the database is created on the secondary servers
20+
21+
On each secondary SQL Server replica, run the following query to see if the `db1` database was created and is synchronized:
22+
23+
```sql
24+
SELECT * FROM sys.databases WHERE name = 'db1';
25+
GO
26+
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;
27+
```
Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
## Prerequisites
2+
3+
Before you create the availability group, you need to:
4+
5+
- Set your environment so that all the servers that will host availability replicas can communicate.
6+
- Install SQL Server. See [Install SQL Server](install-sql-server.md) for details.
7+
8+
## Enable AlwaysOn availability groups and restart mssql-server
9+
10+
>[!NOTE]
11+
>The command used below is utilizing cmdlets from the sqlserver module that is published on the PowerShell Gallery. You can install this module using the Install-Module command.
12+
13+
Enable AlwaysOn availability groups on each replica that hosts a SQL Server instance. Then restart the SQL Server service. Run the following command to enable and the restart the SQL Server services:
14+
15+
```powershell
16+
Enable-SqlAlwaysOn -ServerInstance <server\instance> -Force
17+
```
18+
19+
## Enable an AlwaysOn_health event session
20+
21+
You can optionally enable AlwaysOn availability groups Extended Event (XE) session to help with root-cause diagnosis when you troubleshoot an availability group. Run the following command on each instance of SQL Server:
22+
23+
```sql
24+
ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
25+
GO
26+
```
27+
28+
For more information about this XE session, see [Always On Availability Groups extended events](always-on-extended-events.md).
29+
30+
## Database Mirroring Endpoint Authentication
31+
32+
The replicas involved in the read-scale Availability Group will need to authenticate over the endpoint in order for synchronization to function properly. There are two main scenarios covered below that can be used for such authentication.
33+
34+
### Service Account
35+
36+
In an Active Directory environment where all secondary replicas on joined to the same domain SQL Server can authenticate utilizing the service account. You will need to explicitly create a login for the service account on each all SQL Server instances:
37+
38+
```sql
39+
CREATE LOGIN [<domain>\service account] FROM WINDOWS;
40+
```
41+
42+
### SQL Login Authentication
43+
44+
In environments where the secondary replicas may not be joined to an Active Directory Domain you will need to utilize SQL Authentication. The following Transact-SQL script creates a login named `dbm_login` and a user named `dbm_user`. Update the script with a strong password. To create the database mirroring endpoint user, run the following command on all SQL Server instances:
45+
46+
```sql
47+
CREATE LOGIN dbm_login WITH PASSWORD = '**<1Sample_Strong_Password!@#>**';
48+
CREATE USER dbm_user FOR LOGIN dbm_login;
49+
```
50+
51+
#### Certificate Authentication
52+
53+
If you utilize a secondary replica that requires authentication with SQL Authentication use a certificate for authenticating between the mirroring endpoints.
54+
55+
The following Transact-SQL script creates a master key and a certificate. It then backs up the certificate and secures the file with a private key. Update the script with strong passwords. Run the following script on the primary SQL Server instance to create the certificate:
56+
57+
```sql
58+
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
59+
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
60+
BACKUP CERTIFICATE dbm_certificate
61+
TO FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer'
62+
WITH PRIVATE KEY (
63+
FILE = 'c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk',
64+
ENCRYPTION BY PASSWORD = '**<Private_Key_Password>**'
65+
);
66+
```
67+
68+
At this point, your primary SQL Server replica has a certificate at `c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer` and a private key at `c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk`. Copy these two files to the same location on all servers that will host availability replicas.
69+
70+
Ensure on each secondary replica that the service account for SQL Server has permissions to access the certificate.
71+
72+
#### Create the certificate on secondary servers
73+
74+
The following Transact-SQL script creates a master key and a certificate from the backup that you created on the primary SQL Server replica. The command also authorizes the user to access the certificate. Update the script with strong passwords. The decryption password is the same password that you used to create the `.pvk` file in a previous step. To create the certificate, run the following script on all secondary replicas:
75+
76+
```sql
77+
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
78+
CREATE CERTIFICATE dbm_certificate
79+
AUTHORIZATION dbm_user
80+
FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
81+
WITH PRIVATE KEY (
82+
FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
83+
DECRYPTION BY PASSWORD = '**<Private_Key_Password>**'
84+
);
85+
```
86+
87+
## Create the database mirroring endpoints on all replicas
88+
89+
Database mirroring endpoints use the Transmission Control Protocol (TCP) to send and receive messages between the server instances that participate in database mirroring sessions or host availability replicas. The database mirroring endpoint listens on a unique TCP port number.
90+
91+
The following Transact-SQL script creates a listening endpoint named `Hadr_endpoint` for the availability group. It starts the endpoint and gives connection permission to the service account or SQL Login that you created in a previous step. Before you run the script, replace the values between `**< ... >**`. Optionally you can include an IP address `LISTENER_IP = (0.0.0.0)`. The listener IP address must be an IPv4 address. You can also use `0.0.0.0`.
92+
93+
Update the following Transact-SQL script for your environment on all SQL Server instances:
94+
95+
```SQL
96+
CREATE ENDPOINT [Hadr_endpoint]
97+
AS TCP (LISTENER_PORT = **<5022>**)
98+
FOR DATA_MIRRORING (
99+
ROLE = ALL,
100+
AUTHENTICATION = CERTIFICATE dbm_certificate,
101+
ENCRYPTION = REQUIRED ALGORITHM AES
102+
);
103+
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
104+
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [<service account or user>];
105+
```
106+
107+
The TCP port on the firewall must be open for the listener port.
108+
109+
For more information, see [The database mirroring endpoint (SQL Server)](http://msdn.microsoft.com/library/ms179511.aspx).

docs/t-sql/data-types/numeric-types.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -25,6 +25,8 @@ monikerRange: ">= aps-pdw-2016 || = azuresqldb-current || = azure-sqldw-latest |
2525
[!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] supports the following **numeric** types.
2626

2727
## In this section
28+
29+
[bit &#40;Transact-SQL&#41;](../../t-sql/data-types/bit-transact-sql.md)
2830
[decimal and numeric &#40;Transact-SQL&#41;](../../t-sql/data-types/decimal-and-numeric-transact-sql.md)
2931
[float and real &#40;Transact-SQL&#41;](../../t-sql/data-types/float-and-real-transact-sql.md)
3032
[int, bigint, smallint, and tinyint &#40;Transact-SQL&#41;](../../t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql.md)

docs/t-sql/functions/datediff-big-transact-sql.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -44,7 +44,7 @@ DATEDIFF_BIG ( datepart , startdate , enddate )
4444

4545
## Arguments
4646
*datepart*
47-
The part of *date* to which `DATEDIFF_BIG` adds an **integer** *number*. This table lists all valid *datepart* arguments.
47+
The part of *startdate* and *enddate* that specifies the type of boundary crossed. `DATEDIFF_BIG` will not accept user-defined variable equivalents. This table lists all valid *datepart* arguments.
4848

4949
> [!NOTE]
5050
> `DATEDIFF_BIG` does not accept user-defined variable equivalents for the *datepart* arguments.

0 commit comments

Comments
 (0)