# Microsoft SQL Server (MSSQL) (/docs/connectors/sources/mssql) Sync modes, namespaces and the columns Pipeloom adds are explained once in [Connector concepts](/docs/connectors/concepts); workspace variables and custom components in [Orchestration](/docs/orchestration). Pipeloom's certified MSSQL connector offers the following features: * Multiple methods of keeping your data fresh, including [Change Data Capture (CDC)](/docs/connectors/concepts#change-data-capture) using [SQL Server's CDC feature](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server). * Incremental as well as Full Refresh [sync modes](/docs/connectors/concepts#sync-modes), providing flexibility in how data is delivered to your destination. * Reliable replication at any table size with checkpointing and chunking of database reads. > ⚠️ **Please note the minimum required platform version is v0.58.0 to run source-mssql 4.0.18 and above.** ## Features [#features] | Feature | Supported | Notes | | :---------------------------- | :-------- | :----------------- | | Full Refresh Sync | Yes | | | Incremental Sync - Append | Yes | | | Replicate Incremental Deletes | Yes | | | CDC (Change Data Capture) | Yes | | | SSL Support | Yes | | | SSH Tunnel Connection | Yes | | | Microsoft Entra ID Auth | Yes | Service principal | | Namespaces | Yes | Enabled by default | The MSSQL source does not alter the schema present in your database. Depending on the destination connected to this source, however, the schema may be altered. See the destination's documentation for more details. ## Getting Started [#getting-started] #### Requirements [#requirements] 1. MSSQL Server `Azure SQL Database`, `Azure Synapse Analytics`, `Azure SQL Managed Instance`, `SQL Server 2022`, `SQL Server 2019`, `SQL Server 2017`, `SQL Server 2016`, `SQL Server 2014`, `SQL Server 2012`, `PDW 2008R2 AU34`. 2. Create a dedicated read-only Pipeloom user with access to all tables needed for replication 3. If you want to use CDC, please see [the relevant section below](mssql.md#change-data-capture-cdc) for further setup requirements #### 1. Make sure your database is accessible from the machine running Pipeloom [#1-make-sure-your-database-is-accessible-from-the-machine-running-pipeloom] This is dependent on your networking setup. The easiest way to verify if Pipeloom is able to connect to your MSSQL instance is via the check connection tool in the UI. #### 2. Create a dedicated read-only user with access to the relevant tables (Recommended but optional) [#2-create-a-dedicated-read-only-user-with-access-to-the-relevant-tables-recommended-but-optional] This step is optional but highly recommended to allow for better permission control and auditing. Alternatively, you can use Pipeloom with an existing user in your database. * Create a login and a database user for Pipeloom, then add the user to the [db\_datareader](https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/database-level-roles?view=sql-server-ver16) role. Membership in `db_datareader` grants `SELECT` on all current and future tables in the database: ```text USE {database name}; CREATE LOGIN {user name} WITH PASSWORD = '{password}'; CREATE USER {user name} FOR LOGIN {user name}; ALTER ROLE db_datareader ADD MEMBER {user name}; ``` `ALTER ROLE ... ADD MEMBER` replaces the deprecated `sp_addrolemember` stored procedure, which [Microsoft recommends avoiding in new work](https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-addrolemember-transact-sql). * If you prefer to scope access to specific schemas rather than the whole database, skip the `db_datareader` role and instead grant `SELECT` on each schema you want to replicate from. Re-run this command for each schema: ```text USE {database name}; GRANT SELECT ON SCHEMA :: {schema name} TO {user name}; ``` Use the username and password you created here when configuring the MSSQL source in Pipeloom. If you plan to use CDC, this user also needs the additional CDC-related permissions described in [Setting up CDC for MSSQL](#3-create-a-user-and-grant-appropriate-permissions). #### 3. Your database user should now be ready for use with Pipeloom! [#3-your-database-user-should-now-be-ready-for-use-with-pipeloom] #### Pipeloom [#pipeloom] On Pipeloom, only secured connections to your MSSQL instance are supported in source configuration. You may either configure your connection using one of the supported SSL Methods or by using an SSH Tunnel. ## Authentication with Microsoft Entra ID [#authentication-with-microsoft-entra-id] This connector supports [Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/) (formerly Azure Active Directory) authentication using a service principal, as an alternative to SQL Server username and password authentication. This is the recommended authentication mode for Azure SQL Database and Azure SQL Managed Instance. ### Prerequisites [#prerequisites] 1. An Azure SQL Database, Azure SQL Managed Instance, or SQL Server instance that is configured for Microsoft Entra authentication. For setup instructions, see [Configure and manage Microsoft Entra authentication with Azure SQL](https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-configure). 2. A Microsoft Entra ID [app registration (service principal)](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) with a client secret. 3. A database user created for the service principal, with `SELECT` access to the tables you want to replicate. For instructions, see [Create Microsoft Entra users using service principals](https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-service-principal-tutorial). 4. If you plan to use CDC, the service principal user also needs the CDC-related permissions described in [Setting up CDC for MSSQL](#setting-up-cdc-for-mssql). ### Configuration [#configuration] In the source configuration form, fill in the following fields under **Microsoft Entra ID**: | Field | Description | | :------------------------- | :----------------------------------------------------- | | **Entra ID Client ID** | The application (client) ID of the service principal. | | **Entra ID Client Secret** | The client secret generated for the service principal. | When both fields are provided, the connector authenticates with `ActiveDirectoryServicePrincipal` mode through the Microsoft JDBC driver, and the **Username** and **Password** fields are ignored. If either Entra ID field is empty, the connector falls back to username and password authentication. :::note Entra ID authentication requires an encrypted connection. Set **Encryption** to `Encrypted (trust server certificate)` or `Encrypted (verify certificate)`. The connector fails the configuration check if encryption is disabled while Entra ID fields are set. ::: ## MSSQL Replication Modes [#mssql-replication-modes] ### Incremental Syncs [#incremental-syncs] MSSQL `datetime2(7)` type stores timestamps with up to 7 decimal places, but since most destinations don't support the extra precision, Pipeloom truncates them to 6 (microseconds). Because of that, the saved cursor can land just behind the newest rows in your table. To make sure none of them get skipped, each incremental sync reads everything *above* the saved cursor, then saves the new max value as the cursor for the next sync. :::note Because each sync picks up everything newer than the last saved point, you may see some duplicate rows. If possible, we do recommend using `Incremental - Append + Deduped` for supported syncs. For more information, please visit our [Sync Mode](/docs/connectors/concepts#sync-modes) page. ::: ### Change Data Capture (CDC) [#change-data-capture-cdc] We use [SQL Server's change data capture feature](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server?view=sql-server-2017) with transaction logs to capture row-level `INSERT`, `UPDATE` and `DELETE` operations that occur on CDC-enabled tables. Some extra setup requiring at least *db\_owner* permissions on the database(s) you intend to sync from will be required (detailed [below](mssql.md#setting-up-cdc-for-mssql)). Please read the [CDC docs](/docs/connectors/concepts#change-data-capture) for an overview of how Pipeloom approaches CDC. #### Should I use CDC for MSSQL? [#should-i-use-cdc-for-mssql] * If you need a record of deletions and can accept the limitations posted below, CDC is the way to go! * If your data set is small and/or you just want a snapshot of your table in the destination, consider using Full Refresh replication for your table instead of CDC. * If the limitations below prevent you from using CDC and your goal is to maintain a snapshot of your table in the destination, consider using non-CDC incremental and occasionally reset the data and re-sync. * If your table has a primary key but doesn't have a reasonable cursor field for incremental syncing (i.e. `updated_at`), CDC allows you to sync your table incrementally. #### CDC Limitations [#cdc-limitations] * Make sure to read our [CDC docs](/docs/connectors/concepts#change-data-capture) to see limitations that impact all databases using CDC replication. * `hierarchyid` and `sql_variant` types are not processed in CDC migration type (not supported by Debezium). For more details please check this ticket * CDC is only available for SQL Server 2016 Service Pack 1 (SP1) and later. * *db\_owner* (or higher) permissions are required to perform the [necessary setup](mssql.md#setting-up-cdc-for-mssql) for CDC. * On Linux, CDC is not supported on versions earlier than SQL Server 2017 CU18 (SQL Server 2019 is supported). * Change data capture cannot be enabled on tables with a clustered columnstore index. (It can be enabled on tables with a *non-clustered* columnstore index). * The SQL Server CDC feature processes changes that occur in user-created tables only. You cannot enable CDC on the SQL Server master database. * Using variables with partition switching on databases or tables with change data capture (CDC) is not supported for the `ALTER TABLE` ... `SWITCH TO` ... `PARTITION` ... statement. * CDC incremental syncing is only available for tables with at least one primary key. Tables without primary keys can still be replicated by CDC but only in Full Refresh mode. For more information on CDC limitations, refer to our [CDC Limitations doc](/docs/connectors/concepts#change-data-capture). * Our CDC implementation uses at least once delivery for all change records. * Read more on CDC limitations in the [Microsoft docs](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server?view=sql-server-2017#limitations). #### Setting up CDC for MSSQL [#setting-up-cdc-for-mssql] ##### 1. Enable CDC on database and tables [#1-enable-cdc-on-database-and-tables] MS SQL Server provides some built-in stored procedures to enable CDC. * To enable CDC, a SQL Server administrator with the necessary privileges (*db\_owner* or *sysadmin*) must first run a query to enable CDC at the database level. ```text USE {database name} GO EXEC sys.sp_cdc_enable_db GO ``` * The administrator must then enable CDC for each table that you want to capture. Here's an example: ```text USE {database name} GO EXEC sys.sp_cdc_enable_table @source_schema = N'{schema name}', @source_name = N'{table name}', @role_name = N'{role name}', [1] @filegroup_name = N'{filegroup name}', [2] @supports_net_changes = 0 [3] GO ``` * \[1] Specifies a role which will gain `SELECT` permission on the captured columns of the source table. We suggest putting a value here so you can use this role in the next step but you can also set the value of @role*name to `NULL` to allow only \_sysadmin* and *db\_owner* to have access. Be sure that the credentials used to connect to the source in Pipeloom align with this role so that Pipeloom can access the cdc tables. * \[2] Specifies the filegroup where SQL Server places the change table. We recommend creating a separate filegroup for CDC but you can leave this parameter out to use the default filegroup. * \[3] If 0, only the support functions to query for all changes are generated. If 1, the functions that are needed to query for net changes are also generated. If supports\_net\_changes is set to 1, index\_name must be specified, or the source table must have a defined primary key. * (For more details on parameters, see the [Microsoft doc page](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-enable-table-transact-sql?view=sql-server-ver15) for this stored procedure). * If you have many tables to enable CDC on and would like to avoid having to run this query one-by-one for every table, [this script](http://www.techbrothersit.com/2013/06/change-data-capture-cdc-sql-server_69.html) might help! For further detail, see the [Microsoft docs on enabling and disabling CDC](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/enable-and-disable-change-data-capture-sql-server?view=sql-server-ver15). :::note Google Cloud SQL for SQL Server On [Google Cloud SQL for SQL Server](https://cloud.google.com/sql/docs/sqlserver), Google does not grant customers the `sysadmin` server role, so you cannot run `sys.sp_cdc_enable_db` to enable CDC at the database level. Instead of the database-level command shown above, use Cloud SQL's dedicated stored procedure, which enables CDC without `sysadmin`: ```text EXEC msdb.dbo.gcloudsql_cdc_enable_db 'YOUR_DATABASE_NAME' ``` To disable CDC at the database level later, use the corresponding `EXEC msdb.dbo.gcloudsql_cdc_disable_db 'YOUR_DATABASE_NAME'` procedure. Only the database-level enablement differs on Cloud SQL. Enabling CDC on individual tables still uses the standard `sys.sp_cdc_enable_table` procedure, and the snapshot isolation and user/permission steps below are unchanged. For the full Google-provided procedure, see [Configure CDC for a Cloud SQL for SQL Server source](https://cloud.google.com/datastream/docs/configure-cloudsql-sqlserver). ::: ##### 2. Enable snapshot isolation [#2-enable-snapshot-isolation] * When a sync runs for the first time using CDC, Pipeloom performs an initial consistent snapshot of your database. To avoid acquiring table locks, Pipeloom uses *snapshot isolation*, allowing simultaneous writes by other database clients. This must be enabled on the database like so: ```text ALTER DATABASE {database name} SET ALLOW_SNAPSHOT_ISOLATION ON; ``` ##### 3. Create a user and grant appropriate permissions [#3-create-a-user-and-grant-appropriate-permissions] * Rather than use *sysadmin* or *db\_owner* credentials, we recommend creating a new user with the relevant CDC access for use with Pipeloom. First let's create the login and user and add to the [db\_datareader](https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/database-level-roles?view=sql-server-ver15) role: ```text USE {database name}; CREATE LOGIN {user name} WITH PASSWORD = '{password}'; CREATE USER {user name} FOR LOGIN {user name}; ALTER ROLE db_datareader ADD MEMBER {user name}; ``` * Add the user to the role specified earlier when enabling cdc on the table(s): ```text ALTER ROLE {role name} ADD MEMBER {user name}; ``` * `ALTER ROLE ... ADD MEMBER` replaces the deprecated `sp_addrolemember` stored procedure, which [Microsoft recommends avoiding in new work](https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-addrolemember-transact-sql). * This should be enough access, but if you run into problems, try also directly granting the user `SELECT` access on the cdc schema: ```text USE {database name}; GRANT SELECT ON SCHEMA :: [cdc] TO {user name}; ``` * If feasible, granting this user 'VIEW SERVER STATE' permissions will allow Pipeloom to check whether or not the [SQL Server Agent](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server?view=sql-server-ver15#relationship-with-log-reader-agent) is running. This is preferred as it ensures syncs will fail if the CDC tables are not being updated by the Agent in the source database. ```text USE master; GRANT VIEW SERVER STATE TO {user name}; ``` ##### 4. Extend the retention period of CDC data [#4-extend-the-retention-period-of-cdc-data] * In SQL Server, by default, only three days of data are retained in the change tables. Unless you are running very frequent syncs, we suggest increasing this retention so that in case of a failure in sync or if the sync is paused, there is still some bandwidth to start from the last point in incremental sync. Pipeloom recommends retaining at least 7 days of CDC data. * These settings can be changed using the stored procedure [sys.sp\_cdc\_change\_job](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-change-job-transact-sql?view=sql-server-ver15) as below: ```text -- Pipeloom recommends at least 10080 minutes (7 days) as the retention period EXEC sp_cdc_change_job @job_type='cleanup', @retention = 10080 ``` * After making this change, a restart of the cleanup job is required: ```text EXEC sys.sp_cdc_stop_job @job_type = 'cleanup'; EXEC sys.sp_cdc_start_job @job_type = 'cleanup'; ``` * If you are using Transaction Replication, the retention has to be changed using the following scripts: ```text EXEC sp_changedistributiondb @database = 'distribution', @property = 'max_distretention', @value = 10080 -- 10080 minutes (7 days) EXEC sp_changedistributiondb @database = 'distribution', @property = 'history_retention', @value = 10080 -- 10080 minutes (7 days) USE [msdb] GO EXEC msdb.dbo.sp_update_jobstep @job_name=N'Distribution clean up: distribution', @step_id=1 , @command=N'EXEC dbo.sp_MSdistribution_cleanup @min_distretention = 0, @max_distretention = 10800' GO ``` ##### 5. Ensure the SQL Server Agent is running [#5-ensure-the-sql-server-agent-is-running] * MSSQL uses the SQL Server Agent to [run the jobs necessary](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-data-capture-sql-server?view=sql-server-ver15#agent-jobs) for CDC. It is therefore vital that the Agent is operational in order for CDC to work effectively. You can check the status of the SQL Server Agent as follows: ```text EXEC xp_servicecontrol 'QueryState', N'SQLServerAGENT'; ``` * If you see something other than 'Running.' please follow the [Microsoft docs](https://docs.microsoft.com/en-us/sql/ssms/agent/start-stop-or-pause-the-sql-server-agent-service?view=sql-server-ver15) to start the service. ## Connection to MSSQL via an SSH Tunnel [#connection-to-mssql-via-an-ssh-tunnel] Pipeloom has the ability to connect to a MSSQL instance via an SSH Tunnel. The reason you might want to do this because it is not possible (or against security policy) to connect to the database directly (e.g. it does not have a public IP address). When using an SSH tunnel, you are configuring Pipeloom to connect to an intermediate server (a.k.a. a bastion server) that *does* have direct access to the database. Pipeloom connects to the bastion and then asks the bastion to connect directly to the server. Using this feature requires additional configuration, when creating the source. We will talk through what each piece of configuration means. 1. Configure all fields for the source as you normally would, except `SSH Tunnel Method`. 2. `SSH Tunnel Method` defaults to `No Tunnel` (meaning a direct connection). If you want to use an SSH Tunnel choose `SSH Key Authentication` or `Password Authentication`. 1. Choose `Key Authentication` if you will be using an RSA private key as your secret for establishing the SSH Tunnel (see below for more information on generating this key). 2. Choose `Password Authentication` if you will be using a password as your secret for establishing the SSH Tunnel. 3. `SSH Tunnel Jump Server Host` refers to the intermediate (bastion) server that Pipeloom will connect to. This should be a hostname or an IP Address. 4. `SSH Connection Port` is the port on the bastion server with which to make the SSH connection. The default port for SSH connections is `22`, so unless you have explicitly changed something, go with the default. 5. `SSH Login Username` is the username that Pipeloom should use when connecting to the bastion server. This is NOT the MSSQL username. 6. If you are using `Password Authentication`, then `SSH Login Username` should be set to the password of the User from the previous step. If you are using `SSH Key Authentication` leave this blank. Again, this is not the MSSQL password, but the password for the OS-user that Pipeloom is using to perform commands on the bastion. 7. If you are using `SSH Key Authentication`, then `SSH Private Key` should be set to the RSA private Key that you are using to create the SSH connection. This should be the full contents of the key file starting with `-----BEGIN RSA PRIVATE KEY-----` and ending with `-----END RSA PRIVATE KEY-----`. ### Generating an SSH Key Pair [#generating-an-ssh-key-pair] The connector expects an RSA key in PEM format. To generate this key: ```text ssh-keygen -t rsa -m PEM -f myuser_rsa ``` This produces the private key in pem format, and the public key remains in the standard format used by the `authorized_keys` file on your bastion host. The public key should be added to your bastion host to whichever user you want to use with Pipeloom. The private key is provided via copy-and-paste to the Pipeloom connector configuration screen, so it may log in to the bastion. ## Data type mapping [#data-type-mapping] MSSQL data types are mapped to the following data types when synchronizing data. You can check the test values examples here. If you can't find the data type you are looking for or have any problems feel free to add a new test! | MSSQL Type | Resulting Type | Notes | | :------------------------------------------------------ | :---------------------- | :------------------------------------------- | | `bigint` | integer | | | `binary` | binary | | | `bit` | boolean | | | `char` | string | | | `date` | date | | | `datetime` | timestamp | | | `datetime2` | timestamp | | | `datetimeoffset` | timestamp with timezone | | | `decimal` | number / integer | maps to `integer` when the column scale is 0 | | `int` | integer | | | `float` | number | | | `geography` | string | | | `geometry` | string | | | `money` | number | | | `numeric` | number / integer | maps to `integer` when the column scale is 0 | | `ntext` | string | | | `nvarchar` | string | | | `nvarchar(max)` | string | | | `real` | number | | | `smalldatetime` | timestamp | | | `smallint` | integer | | | `smallmoney` | number | | | `sql_variant` | string | | | `uniqueidentifier` | string | | | `text` | string | | | `time` | time | | | `tinyint` | integer | | | `varbinary` | binary | | | `varchar` | string | | | `varchar(max) COLLATE Latin1_General_100_CI_AI_SC_UTF8` | string | | | `hierarchyid` | string | Non-CDC only | | `xml` | string | | If you do not see a type in this list, assume that it is coerced into a string. We are happy to take feedback on preferred mappings. ## Upgrading to version 4.3.0 and above [#upgrading-to-version-430-and-above] Version 4.3.0 introduces a migration from the legacy CDK to the new CDK architecture. This migration includes: * **Automatic State Migration**: The connector automatically migrates legacy version 2 state formats to the new version 3 format. This includes: * `OrderedColumnLoadStatus` (primary key-based initial sync) → version 3 `primary_key` state type * `CursorBasedStatus` (cursor-based incremental) → version 3 `cursor_based` state type * **Backward Compatibility**: Existing connections will continue to work seamlessly without any manual intervention ## Upgrading from 0.4.17 and older versions to 0.4.18 and newer versions [#upgrading-from-0417-and-older-versions-to-0418-and-newer-versions] There is a backwards incompatible spec change between Microsoft SQL Source connector versions 0.4.17 and 0.4.18. As part of that spec change `replication_method` configuration parameter was changed to `object` from `string`. In Microsoft SQL source connector versions 0.4.17 and older, `replication_method` configuration parameter was saved in the configuration database as follows: ``` "replication_method": "STANDARD" ``` Starting with version 0.4.18, `replication_method` configuration parameter is saved as follows: ``` "replication_method": { "method": "STANDARD" } ``` After upgrading Microsoft SQL Source connector from 0.4.17 or older version to 0.4.18 or newer version you need to fix source configurations in the `actor` table in Pipeloom database. To do so, you need to run two SQL queries. Follow the instructions in Pipeloom documentation to run SQL queries on Pipeloom database. If you have connections with Microsoft SQL Source using *Standard* replication method, run this SQL: ```sql update public.actor set configuration =jsonb_set(configuration, '{replication_method}', '{"method": "STANDARD"}', true) WHERE actor_definition_id ='b5ea17b1-f170-46dc-bc31-cc744ca984c1' AND (configuration->>'replication_method' = 'STANDARD'); ``` If you have connections with Microsoft SQL Source using *Logical Replication (CDC)* method, run this SQL: ```sql update public.actor set configuration =jsonb_set(configuration, '{replication_method}', '{"method": "CDC"}', true) WHERE actor_definition_id ='b5ea17b1-f170-46dc-bc31-cc744ca984c1' AND (configuration->>'replication_method' = 'CDC'); ``` ## IP allow list [#ip-allow-list] If you use Pipeloom and your organization restricts access to specific IPs, add the [Pipeloom IP addresses](/docs/connectors/concepts#ip-allow-list) to your allow list.