Перемещение данных в базу данных SQL Server и из нее с помощью фабрики данных Azure

Примечание

В этой статье рассматривается служба "Фабрика данных Azure" версии 1. Если вы используете текущую версию Фабрики данных, см. статью о соединителе SQL Server в службе "Фабрика данных Azure" версии 2.

В этой статье рассказывается, как с помощью действия копирования в Фабрике данных Azure перемещать данные в базу данных SQL Server и обратно. Этот документ является продолжением статьи о действиях перемещения данных, в которой приведены общие сведения о перемещении данных с помощью действия копирования.

Примечание

Эта статья была изменена, и теперь в ней содержатся сведения о модуле Az PowerShell для Azure. Модуль Az PowerShell является рекомендуемым модулем PowerShell для взаимодействия с Azure. Чтобы начать работу с модулем Az PowerShell, ознакомьтесь со статьей Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

Поддерживаемые сценарии

Данные можно скопировать из базы данных SQL Server в следующие хранилища данных:

Категория Хранилище данных
Azure Хранилище BLOB-объектов Azure
Azure Data Lake Storage 1-го поколения
Azure Cosmos DB (SQL API)
База данных SQL Azure
Azure Synapse Analytics
Индекс Когнитивного поиска Azure
Хранилище таблиц Azure
Базы данных SQL Server
Oracle
Файл Файловая система

Данные можно скопировать в базу данных SQL Server из следующих хранилищ данных:

Категория Хранилище данных
Azure Хранилище BLOB-объектов Azure
Azure Cosmos DB (SQL API)
Azure Data Lake Storage 1-го поколения
База данных SQL Azure
Azure Synapse Analytics
Хранилище таблиц Azure
Базы данных Amazon Redshift
DB2
MySQL
Oracle
PostgreSQL
SAP Business Warehouse
SAP HANA
SQL Server
Sybase
Teradata
NoSQL Cassandra
MongoDB
Файл Amazon S3
Файловая система
FTP
HDFS
SFTP
Другие Базовый протокол HTTP
Базовый протокол OData
Базовый протокол ODBC
Salesforce
Веб-таблица (таблица на основе HTML)

Поддерживаемые версии SQL Server

Этот соединитель SQL Server поддерживает копирование данных в экземпляры следующих версий, размещенные в локальной среде или в Azure IaaS, и обратно с использованием проверки подлинности SQL и Windows: SQL Server 2016, SQL Server 2014, SQL Server 2012, SQL Server 2008 R2, SQL Server 2008, SQL Server 2005.

Включение соединения

Где бы ни размещалась система SQL Server — локально или на виртуальных машинах Azure IaaS (инфраструктура как услуга), — основные понятия и действия, необходимые для соединения с ней, одинаковы. В обоих случаях для подключения необходимо использовать шлюз управления данными.

В статье Перемещение данных между локальными и облачными ресурсами приведены сведения о шлюзе управления данными и пошаговые инструкции по его настройке. Настройка экземпляра шлюза необходима для подключения к SQL Server.

Вы можете установить шлюз на тот же локальный компьютер или экземпляр облачной виртуальной машины, на котором установлена система SQL Server, однако для более эффективной работы мы рекомендуем устанавливать их на разные компьютеры. Размещение шлюза и SQL Server на разных компьютерах уменьшает конкуренцию за ресурсы.

Начало работы

Можно создать конвейер с действием копирования, которое перемещает данные из базы данных SQL Server или в нее с помощью различных инструментов и интерфейсов API.

Проще всего создать конвейер с помощью мастера копирования. В статье Руководство. Создание конвейера с действием копирования с помощью мастера копирования фабрики данных приведены краткие пошаговые указания по созданию конвейера с помощью мастера копирования данных.

Вы также можете использовать следующие инструменты для создания конвейера: Visual Studio, Azure PowerShell, шаблон Azure Resource Manager, .NET API, а также REST API. Пошаговые инструкции по созданию конвейера с действием копирования см. в руководстве по действию копирования.

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

  1. Создание фабрики данных. Фабрика данных может содержать один или несколько конвейеров.
  2. Создайте связанные службы, чтобы связать входные и выходные данные с фабрикой данных. Например, при копировании данных из базы данных SQL Server в хранилище BLOB-объектов Azure создайте две связанные службы, чтобы связать базу данных SQL Server и учетную запись хранения Azure с фабрикой данных. Сведения о свойствах связанной службы, относящихся к базе данных SQL Server, см. в разделе Свойства связанной службы.
  3. Создайте наборы данных, которые представляют входные и выходные данные для операции копирования. В примере, упомянутом в последнем шаге, создайте набор данных, чтобы указать таблицу SQL в базе данных SQL Server, содержащую входные данные. И создайте другой набор данных, чтобы указать контейнер BLOB-объектов и папку, содержащую данные, скопированные из базы данных SQL Server. Сведения о свойствах набора данных, относящихся к базе данных SQL Server, см. в разделе Свойства набора данных.
  4. Создайте конвейер с действием копирования, который принимает входной набор данных и возвращает выходной набор данных. В примере выше SqlSource используется как источник, а BlobSink — как приемник для действия копирования. Аналогично, при копировании из хранилища BLOB-объектов Azure в базу данных SQL Server в действии копирования используются BlobSource и SqlSink. Сведения о свойствах действия копирования, относящихся к базе данных SQL Server, см. в разделе Свойства действия копирования. Для получения сведений о том, как использовать хранилище данных в качестве источника или приемника, щелкните ссылку в предыдущем разделе об источнике данных.

Если вы используете мастер, то он автоматически создает определения JSON для сущностей фабрики данных (связанных служб, наборов данных и конвейера). При использовании инструментов и интерфейсов API (за исключением API .NET) вы самостоятельно определяете эти сущности фабрики данных в формате JSON. Примеры с определениями JSON для сущностей фабрики данных, которые используются для копирования данных из базы данных SQL Server, см. в разделе Примеры определений JSON этой статьи.

Следующие разделы содержат сведения о свойствах JSON, которые используются для определения сущностей фабрики данных, характерных для базы данных SQL Server.

Свойства связанной службы

Создайте связанную службу типа OnPremisesSqlServer, чтобы связать базу данных SQL Server с фабрикой данных. В следующей таблице содержится описание элементов JSON, которые относятся к связанной службе SQL Server.

В следующей таблице содержится описание элементов JSON, которые относятся к связанной службе SQL Server.

Свойство Описание Обязательно
type Свойству type необходимо присвоить значение OnPremisesSqlServer. Да
connectionString Укажите сведения о параметре connectionString, необходимые для подключения к базе данных SQL Server с помощью проверки подлинности SQL или Windows. Да
gatewayName Имя шлюза, который служба "Фабрика данных" должна использовать для подключения к базе данных SQL Server. Да
username При использовании проверки подлинности Windows укажите имя пользователя. Например, domainname\username. Нет
password Введите пароль для учетной записи пользователя, указанной для выбранного имени пользователя. Нет

Вы можете зашифровать учетные данные с помощью командлета New-AzDataFactoryEncryptValue и использовать их в строке подключения, как показано в следующем примере (свойство EncryptedCredential):

"connectionString": "Data Source=<servername>;Initial Catalog=<databasename>;Integrated Security=True;EncryptedCredential=<encrypted credential>",

Примеры

JSON для использования проверки подлинности SQL

{
    "name": "MyOnPremisesSQLDB",
    "properties":
    {
        "type": "OnPremisesSqlServer",
        "typeProperties": {
            "connectionString": "Data Source=<servername>;Initial Catalog=MarketingCampaigns;Integrated Security=False;User ID=<username>;Password=<password>;",
            "gatewayName": "<gateway name>"
        }
    }
}

JSON для использования проверки подлинности Windows

Шлюз управления данными будет действовать от имени соответствующей учетной записи пользователя для подключения к базе данных SQL Server.

{
    "Name": " MyOnPremisesSQLDB",
    "Properties":
    {
        "type": "OnPremisesSqlServer",
        "typeProperties": {
            "ConnectionString": "Data Source=<servername>;Initial Catalog=MarketingCampaigns;Integrated Security=True;",
            "username": "<domain\\username>",
            "password": "<password>",
            "gatewayName": "<gateway name>"
        }
    }
}

Свойства набора данных

В примерах использовался набор данных типа SqlServerTable для представления таблицы в базе данных SQL Server.

Полный список разделов и свойств, используемых для определения наборов данных, см. в статье Наборы данных. Разделы JSON набора данных, такие как структура, доступность и политика, одинаковы для всех типов наборов данных (SQL Server, большой двоичный объект Azure, таблица Azure и т. д.).

Раздел typeProperties во всех типах наборов данных разный. В нем содержатся сведения о расположении данных в хранилище данных. Раздел typeProperties для набора данных с типом SqlServerTable содержит следующие свойства.

Свойство Описание Обязательно
tableName Имя таблицы или представления в экземпляре базы данных SQL Server, на который ссылается связанная служба. Да

Свойства действия копирования

При перемещении данных из базы данных SQL Server в действии копирования задается тип источника SqlSource. Аналогично, при перемещении данных в базу данных SQL Server в действии копирования задается тип источника SqlSink. Этот раздел содержит список свойств, поддерживаемых типами SqlSource и SqlSink.

Полный список разделов и свойств, используемых для определения действий, см. в статье Создание конвейеров. Свойства (такие как имя, описание, входные и выходные таблицы, политики и т. д.) доступны для всех типов действий.

Примечание

Действие копирования принимает только один набор входных данных и возвращает только один набор выходных.

В свою очередь свойства, доступные в разделе typeProperties действия, зависят от конкретного типа действия. Для действия копирования они различаются в зависимости от типов источников и приемников.

SqlSource

Когда источник в действии копирования относится к типу SqlSource, в разделе typeProperties доступны указанные ниже свойства:

Свойство Описание Допустимые значения Обязательно
sqlReaderQuery Используйте пользовательский запрос для чтения данных. Строка запроса SQL. Например, select * from MyTable. Может ссылаться на несколько таблиц из базы данных, на которую ссылается входной набор данных. Если не указано другое, выполняется инструкция SQL select from MyTable. нет
sqlReaderStoredProcedureName Имя хранимой процедуры, которая считывает данные из исходной таблицы. Имя хранимой процедуры. Последней инструкцией SQL должна быть инструкция SELECT в хранимой процедуре. нет
storedProcedureParameters Параметры для хранимой процедуры. Пары имен и значений. Имена и регистр параметров должны совпадать с именами и регистром параметров хранимой процедуры. нет

Если для SqlSource указано sqlReaderQuery , то действие копирования выполняет этот запрос для источника базы данных SQL Server с целью получения данных.

Кроме того, можно создать хранимую процедуру, указав sqlReaderStoredProcedureName и storedProcedureParameters (если хранимая процедура принимает параметры).

Если не указать sqlReaderQuery или sqlReaderStoredProcedureName, то для построения запроса select к базе данных SQL Server будут использованы столбцы, определенные в разделе структуры. Если у определения набора данных нет структуры, выбираются все столбцы из таблицы.

Примечание

При использовании sqlReaderStoredProcedureName по-прежнему необходимо указать значение свойства tableName в наборе данных JSON. Хотя какие-либо проверки этой таблицы отсутствуют.

SqlSink

SqlSink поддерживает указанные ниже свойства.

Свойство Описание Допустимые значения Обязательно
writeBatchTimeout Время ожидания до выполнения операции пакетной вставки, пока не завершится срок ее действия. Интервал времени

Пример "00:30:00" (30 минут).
Нет
writeBatchSize Вставляет данные в таблицу SQL, когда размер буфера достигает значения writeBatchSize. Целое число (количество строк) Нет (значение по умолчанию — 10 000).
sqlWriterCleanupScript Укажите запрос на выполнение действия копирования, позволяющий убедиться в том, что данные конкретного среза очищены. Дополнительные сведения см. в разделе Повторяющаяся операция копирования. Инструкция запроса. Нет
sliceIdentifierColumnName Укажите имя столбца, в которое действие копирования добавляет автоматически созданный идентификатор среза. Этот идентификатор используется для очистки данных конкретного среза при повторном запуске. Дополнительные сведения см. в разделе Повторяющаяся операция копирования. Имя столбца с типом данных binary(32). Нет
sqlWriterStoredProcedureName Имя хранимой процедуры, в которой определяется, как применить исходные данные в целевой таблице. Например, можно определить выполнение операций upsert или преобразований с помощью вашей собственной бизнес-логики.

Обратите внимание, что эта хранимая процедура будет вызываться для каждого пакета. Чтобы однократно выполнить операцию, в которой не используются исходные данные, например удаление или усечение, примените свойство sqlWriterCleanupScript.
Имя хранимой процедуры. нет
storedProcedureParameters Параметры для хранимой процедуры. Пары имен и значений. Имена и регистр параметров должны совпадать с именами и регистром параметров хранимой процедуры. Нет
sqlWriterTableType Укажите имя типа таблицы для использования в хранимой процедуре. Действие копирования делает перемещаемые данные доступными во временной таблице этого типа. Код хранимой процедуры затем можно использовать для объединения копируемых и существующих данных. Имя типа таблицы. Нет

Примеры JSON для копирования данных в SQL Server и обратно

Ниже приведены примеры с определениями JSON, которые можно использовать для создания конвейера с помощью Visual Studio или Azure PowerShell. В следующих примерах показано, как копировать данные в базу данных SQL Server и хранилище BLOB-объектов Azure и обратно. Тем не менее данные можно копировать непосредственно из любых источников в любой указанный здесь приемник. Это делается с помощью действия копирования в фабрике данных Azure.

Пример. Копирование данных из базы данных SQL Server в хранилище BLOB-объектов Azure

В примере ниже используется следующее:

  1. Связанная служба типа OnPremisesSqlServer.
  2. Связанная служба типа AzureStorage.
  3. Входной набор данных типа SqlServerTable.
  4. Выходной набор данных типа AzureBlob.
  5. Конвейер с действием копирования, в котором используются SqlSource и BlobSink.

В этом примере данные временного ряда каждый час копируются из таблицы SQL Server в большой двоичный объект Azure. Используемые в этих примерах свойства JSON описаны в разделах, следующих за примерами.

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

Связанная служба SQL Server

{
  "Name": "SqlServerLinkedService",
  "properties": {
    "type": "OnPremisesSqlServer",
    "typeProperties": {
      "connectionString": "Data Source=<servername>;Initial Catalog=<databasename>;Integrated Security=False;User ID=<username>;Password=<password>;",
      "gatewayName": "<gatewayname>"
    }
  }
}

Связанная служба хранилища BLOB-объектов Azure

{
  "name": "StorageLinkedService",
  "properties": {
    "type": "AzureStorage",
    "typeProperties": {
      "connectionString": "DefaultEndpointsProtocol=https;AccountName=<accountname>;AccountKey=<accountkey>"
    }
  }
}

Входной набор данных SQL Server

В примере предполагается, что вы уже создали таблицу MyTable в SQL Server и она содержит столбец с именем timestampcolumn для данных временного ряда. Можно выполнить запрос к нескольким таблицам в одной базе данных, используя один набор данных, но для typeProperty tableName набора данных нужно указать одну таблицу.

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

{
  "name": "SqlServerInput",
  "properties": {
    "type": "SqlServerTable",
    "linkedServiceName": "SqlServerLinkedService",
    "typeProperties": {
      "tableName": "MyTable"
    },
    "external": true,
    "availability": {
      "frequency": "Hour",
      "interval": 1
    },
    "policy": {
      "externalData": {
        "retryInterval": "00:01:00",
        "retryTimeout": "00:10:00",
        "maximumRetry": 3
      }
    }
  }
}

Выходной набор данных BLOB-объекта Azure

Данные записываются в новый BLOB-объект каждый час (frequency: hour, interval: 1). Путь к папке BLOB-объекта вычисляется динамически на основе времени начала обрабатываемого среза. В пути к папке используется год, месяц, день и час времени начала.

{
  "name": "AzureBlobOutput",
  "properties": {
    "type": "AzureBlob",
    "linkedServiceName": "StorageLinkedService",
    "typeProperties": {
      "folderPath": "mycontainer/myfolder/yearno={Year}/monthno={Month}/dayno={Day}/hourno={Hour}",
      "partitionedBy": [
        {
          "name": "Year",
          "value": {
            "type": "DateTime",
            "date": "SliceStart",
            "format": "yyyy"
          }
        },
        {
          "name": "Month",
          "value": {
            "type": "DateTime",
            "date": "SliceStart",
            "format": "MM"
          }
        },
        {
          "name": "Day",
          "value": {
            "type": "DateTime",
            "date": "SliceStart",
            "format": "dd"
          }
        },
        {
          "name": "Hour",
          "value": {
            "type": "DateTime",
            "date": "SliceStart",
            "format": "HH"
          }
        }
      ],
      "format": {
        "type": "TextFormat",
        "columnDelimiter": "\t",
        "rowDelimiter": "\n"
      }
    },
    "availability": {
      "frequency": "Hour",
      "interval": 1
    }
  }
}

Конвейер с действием копирования

Конвейер содержит действие копирования, которое использует эти входной и выходной наборы данных и выполняется каждый час. В определении JSON конвейера для типа source установлено значение SqlSource, а для типа sink — значение BlobSink. SQL-запрос, указанный для свойства SqlReaderQuery , выбирает для копирования данные за последний час.

{
  "name":"SamplePipeline",
  "properties":{
    "start":"2016-06-01T18:00:00",
    "end":"2016-06-01T19:00:00",
    "description":"pipeline for copy activity",
    "activities":[
      {
        "name": "SqlServertoBlob",
        "description": "copy activity",
        "type": "Copy",
        "inputs": [
          {
            "name": " SqlServerInput"
          }
        ],
        "outputs": [
          {
            "name": "AzureBlobOutput"
          }
        ],
        "typeProperties": {
          "source": {
            "type": "SqlSource",
            "SqlReaderQuery": "$$Text.Format('select * from MyTable where timestampcolumn >= \\'{0:yyyy-MM-dd HH:mm}\\' AND timestampcolumn < \\'{1:yyyy-MM-dd HH:mm}\\'', WindowStart, WindowEnd)"
          },
          "sink": {
            "type": "BlobSink"
          }
        },
        "scheduler": {
          "frequency": "Hour",
          "interval": 1
        },
        "policy": {
          "concurrency": 1,
          "executionPriorityOrder": "OldestFirst",
          "retry": 0,
          "timeout": "01:00:00"
        }
      }
    ]
  }
}

В этом примере для свойства SqlSource указано sqlReaderQuery . Действие копирования выполняет этот запрос к источнику базы данных SQL Server с целью получения данных. Кроме того, можно создать хранимую процедуру, указав sqlReaderStoredProcedureName и storedProcedureParameters (если хранимая процедура принимает параметры). Свойство sqlReaderQuery может ссылаться на несколько таблиц из базы данных, на которую ссылается входной набор данных. Он не ограничивается таблицей, заданной свойством typeProperty в качестве параметра tableName набора данных.

Если не указать sqlReaderQuery или sqlReaderStoredProcedureName, то для построения запроса select к базе данных SQL Server будут использованы столбцы, определенные в разделе структуры. Если у определения набора данных нет структуры, выбираются все столбцы из таблицы.

Список свойств, поддерживаемых SqlSource и BlobSink, см. в разделах SqlSource и BlobSink.

Пример. Копирование данных из BLOB-объекта Azure в базу данных SQL Server

В примере ниже используется следующее:

  1. Связанная служба типа OnPremisesSqlServer.
  2. Связанная служба типа AzureStorage.
  3. Входной набор данных типа AzureBlob.
  4. Выходной набор данных типа SqlServerTable.
  5. Конвейер с действием копирования, в котором используются BlobSource и SqlSink.

В этом примере данные временного ряда каждый час копируются из большого двоичного объекта Azure в таблицу SQL Server. Используемые в этих примерах свойства JSON описаны в разделах, следующих за примерами.

Связанная служба SQL Server

{
  "Name": "SqlServerLinkedService",
  "properties": {
    "type": "OnPremisesSqlServer",
    "typeProperties": {
      "connectionString": "Data Source=<servername>;Initial Catalog=<databasename>;Integrated Security=False;User ID=<username>;Password=<password>;",
      "gatewayName": "<gatewayname>"
    }
  }
}

Связанная служба хранилища BLOB-объектов Azure

{
  "name": "StorageLinkedService",
  "properties": {
    "type": "AzureStorage",
    "typeProperties": {
      "connectionString": "DefaultEndpointsProtocol=https;AccountName=<accountname>;AccountKey=<accountkey>"
    }
  }
}

Входной набор данных BLOB-объекта Azure

Данные берутся из нового BLOB-объекта каждый час (frequency: hour, interval: 1). Путь к папке с BLOB-объектом и имя файла вычисляются динамически на основе времени начала обрабатываемого среза. В пути к папке используется год, месяц и день начала, а в имени файла — час начала. Параметр "external": "true" сообщает службе фабрики данных, что набор данных является внешним по отношению к фабрике данных и не создается в результате действия в фабрике данных.

{
  "name": "AzureBlobInput",
  "properties": {
    "type": "AzureBlob",
    "linkedServiceName": "StorageLinkedService",
    "typeProperties": {
      "folderPath": "mycontainer/myfolder/yearno={Year}/monthno={Month}/dayno={Day}",
      "fileName": "{Hour}.csv",
      "partitionedBy": [
        {
          "name": "Year",
          "value": {
            "type": "DateTime",
            "date": "SliceStart",
            "format": "yyyy"
          }
        },
        {
          "name": "Month",
          "value": {
            "type": "DateTime",
            "date": "SliceStart",
            "format": "MM"
          }
        },
        {
          "name": "Day",
          "value": {
            "type": "DateTime",
            "date": "SliceStart",
            "format": "dd"
          }
        },
        {
          "name": "Hour",
          "value": {
            "type": "DateTime",
            "date": "SliceStart",
            "format": "HH"
          }
        }
      ],
      "format": {
        "type": "TextFormat",
        "columnDelimiter": ",",
        "rowDelimiter": "\n"
      }
    },
    "external": true,
    "availability": {
      "frequency": "Hour",
      "interval": 1
    },
    "policy": {
      "externalData": {
        "retryInterval": "00:01:00",
        "retryTimeout": "00:10:00",
        "maximumRetry": 3
      }
    }
  }
}

Выходной набор данных SQL Server

В этом примере данные копируются в таблицу "MyTable", которая создана в базе данных SQL Server. Создайте в базе данных SQL Server таблицу с тем же количеством столбцов, которое должно быть в CSV-файле большого двоичного объекта. Новые строки добавляются в таблицу каждый час.

{
  "name": "SqlServerOutput",
  "properties": {
    "type": "SqlServerTable",
    "linkedServiceName": "SqlServerLinkedService",
    "typeProperties": {
      "tableName": "MyOutputTable"
    },
    "availability": {
      "frequency": "Hour",
      "interval": 1
    }
  }
}

Конвейер с действием копирования

Конвейер содержит действие копирования, которое использует эти входной и выходной наборы данных и выполняется каждый час. В определении JSON конвейера для типа source установлено значение BlobSource, а для типа sink — значение SqlSink.

{
  "name":"SamplePipeline",
  "properties":{
    "start":"2014-06-01T18:00:00",
    "end":"2014-06-01T19:00:00",
    "description":"pipeline with copy activity",
    "activities":[
      {
        "name": "AzureBlobtoSQL",
        "description": "Copy Activity",
        "type": "Copy",
        "inputs": [
          {
            "name": "AzureBlobInput"
          }
        ],
        "outputs": [
          {
            "name": " SqlServerOutput "
          }
        ],
        "typeProperties": {
          "source": {
            "type": "BlobSource",
            "blobColumnSeparators": ","
          },
          "sink": {
            "type": "SqlSink"
          }
        },
        "scheduler": {
          "frequency": "Hour",
          "interval": 1
        },
        "policy": {
          "concurrency": 1,
          "executionPriorityOrder": "OldestFirst",
          "retry": 0,
          "timeout": "01:00:00"
        }
      }
    ]
  }
}

Устранение неполадок с подключением

  1. Настройте SQL Server для приема удаленных подключений. Запустите SQL Server Management Studio, щелкните правой кнопкой мыши свой сервер и выберите пункт Свойства. Выберите в списке пункт Подключения и установите флажок Allow remote connections to the server (Разрешить удаленные подключения к этому серверу).

    Включение удаленных подключений

    Подробные инструкции см. в статье Настройка параметра конфигурации сервера remote access.

  2. Запустите диспетчер конфигурации SQL Server. Разверните узел Сетевая конфигурация SQL Server для нужного экземпляра и выберите пункт Protocols for MSSQLSERVER (Протоколы для MSSQLSERVER). Вы должны увидеть протоколы на панели справа. Включите TCP/TP, щелкнув правой кнопкой мыши имя протокола TCP/IP и выбрав пункт Включить.

    Включение TCP/IP

    Подробные сведения и альтернативные способы включения протокола TCP/IP см. в статье Включение или отключение сетевого протокола сервера.

  3. В этом же окне дважды щелкните TCP/IP, чтобы открыть окно TCP/IP Properties (Свойства TCP/IP).

  4. Перейдите на вкладку IP-адреса. Прокрутите вниз до раздела IPAll. Запишите значение параметра Порт TCP (1433 по умолчанию).

  5. Создайте на компьютере правило брандмауэра Windows , чтобы разрешить входящий трафик через этот порт.

  6. Проверьте подключение. Например, <machine><domain>.corp<company>.com,1433.

    Важно!

    Дополнительные сведения см. в статье Перемещение данных между локальными источниками и облаком с помощью шлюза управления данными.

    Советы по устранению неполадок, связанных со шлюзом или подключением, см. в разделе Устранение неполадок в работе шлюза.

Столбцы идентификаторов в целевой базе данных

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

Исходная таблица:

create table dbo.SourceTbl
(
    name varchar(100),
    age int
)

Целевая таблица:

create table dbo.TargetTbl
(
    identifier int identity(1,1),
    name varchar(100),
    age int
)

Обратите внимание, что в целевой таблице есть столбец идентификаторов.

Определение JSON исходного набора данных

{
    "name": "SampleSource",
    "properties": {
        "published": false,
        "type": " SqlServerTable",
        "linkedServiceName": "TestIdentitySQL",
        "typeProperties": {
            "tableName": "SourceTbl"
        },
        "availability": {
            "frequency": "Hour",
            "interval": 1
        },
        "external": true,
        "policy": {}
    }
}

Определение JSON целевого набора данных

{
    "name": "SampleTarget",
    "properties": {
        "structure": [
            { "name": "name" },
            { "name": "age" }
        ],
        "published": false,
        "type": "AzureSqlTable",
        "linkedServiceName": "TestIdentitySQLSource",
        "typeProperties": {
            "tableName": "TargetTbl"
        },
        "availability": {
            "frequency": "Hour",
            "interval": 1
        },
        "external": false,
        "policy": {}
    }
}

Обратите внимание, что у исходной и целевой таблиц разные схемы (в целевой есть дополнительный столбец с идентификаторами). В этом случае необходимо указать свойство structure в определении целевого набора данных, которое не включает в себя столбец идентификаторов.

Вызов хранимой процедуры из приемника SQL

Пример вызова хранимой процедуры из приемника SQL в действии копирования в конвейере приведен в статье Invoke stored procedure from copy activity in Azure Data Factory (Вызов хранимой процедуры из действия копирования в фабрике данных Azure).

Сопоставление типов SQL Server

Как упоминалось в статье о действиях перемещения данных, во время копирования типы источников автоматически преобразовываются в типы приемников. Такое преобразование выполняется в 2 этапа:

  1. Преобразование собственных типов источников в тип .NET.
  2. Преобразование типа .NET в собственный тип приемника.

Когда данные перемещаются в базу данных SQL Server и обратно, для преобразования типа SQL в тип .NET и наоборот используются следующие сопоставления.

Сопоставление аналогично сопоставлению типов данных SQL Server для ADO.NET.

Тип ядра СУБД SQL Server Тип платформы .NET Framework
BIGINT Int64
binary Byte[]
bit Логическое
char String, Char[]
Дата Дата и время
Datetime Дата и время
datetime2 Дата и время
Datetimeoffset DateTimeOffset
Decimal Decimal
FILESTREAM attribute (varbinary(max)) Byte[]
Float Double
Изображение Byte[]
INT Int32
money Decimal
nchar String, Char[]
ntext String, Char[]
NUMERIC Decimal
nvarchar String, Char[]
real Один
rowversion Byte[]
smalldatetime Дата и время
smallint Int16
smallmoney Decimal
sql_variant Object *
текст String, Char[]
time TimeSpan
TIMESTAMP Byte[]
tinyint Byte
UNIQUEIDENTIFIER Guid
varbinary Byte[]
varchar String, Char[]
xml Xml

Сопоставление столбцов источника и приемника

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

Повторяющаяся операция копирования

При копировании данных в базу данных SQL Server действие копирования по умолчанию добавляет данные в таблицу приемника. Чтобы вместо этого выполнить операцию UPSERT, изучите раздел Повторяемая запись в SqlSink.

При копировании данных из реляционных хранилищ важно помнить о повторяемости, чтобы избежать непредвиденных результатов. В фабрике данных Azure можно вручную повторно выполнить срез. Вы можете также настроить для набора данных политику повтора, чтобы при сбое срез выполнялся повторно. При повторном выполнении среза в любом случае необходимо убедиться в том, что считываются те же данные, независимо от того, сколько раз выполняется срез. Ознакомьтесь с разделом Повторяющиеся операции чтения из реляционных источников.

Производительность и настройка

Ознакомьтесь со статьей Руководство по настройке производительности действия копирования, в которой описываются ключевые факторы, влияющие на производительность перемещения данных (действие копирования) в фабрике данных Azure, и различные способы оптимизации этого процесса.