Compartilhar via

Arquivos de dados do SQL Server no Azure

Os Arquivos de Dados do SQL Server no Azure permitem suporte nativo para arquivos de banco de dados do SQL Server armazenados como Blobs do Azure. Ele permite que você crie um banco de dados no SQL Server em execução no local ou em uma máquina virtual no Azure com um local de armazenamento dedicado para seus dados no Armazenamento de Blobs do Azure. Esse aprimoramento simplifica especialmente a movimentação de bancos de dados entre computadores usando operações de desanexação e anexação. Além disso, ele fornece um local de armazenamento alternativo para os arquivos de backup do banco de dados, permitindo que você restaure de ou para o Armazenamento do Azure. Portanto, ele permite várias soluções híbridas fornecendo vários benefícios para virtualização de dados, movimentação de dados, segurança e disponibilidade e quaisquer custos e manutenção fáceis baixos para alta disponibilidade e dimensionamento elástico.

Este tópico apresenta conceitos e considerações que são centrais para armazenar arquivos de dados do SQL Server no Serviço de Armazenamento do Azure.

Para obter uma experiência prática prática sobre como usar esse novo recurso, consulte Tutorial: Arquivos de Dados do SQL Server no serviço de Armazenamento do Azure.

O diagrama a seguir demonstra que esse aprimoramento permite armazenar arquivos de banco de dados do SQL Server como blobs do Azure no Armazenamento do Azure, independentemente de onde o servidor reside.

Integração do SQL Server com o Armazenamento do Azure

Benefícios de usar arquivos de dados do SQL Server no Azure

  • Benefícios de migração fáceis e rápidos: Esse recurso simplifica o processo de migração movendo um banco de dados por vez entre computadores no local, bem como entre ambientes locais e de nuvem sem nenhuma alteração de aplicativo. Portanto, ele dá suporte a uma migração incremental, mantendo sua infraestrutura local existente em vigor. Além disso, ter acesso a um armazenamento de dados centralizado simplifica a lógica do aplicativo quando um aplicativo precisa ser executado em vários locais em um ambiente local. Em alguns casos, talvez seja necessário configurar rapidamente centros de computador em locais geograficamente dispersos, que coletam dados de várias fontes diferentes. Ao usar esse novo aprimoramento, em vez de mover dados de um local para outro, você pode armazenar muitos bancos de dados como blobs do Azure e, em seguida, executar Transact-SQL scripts para criar bancos de dados em máquinas virtuais ou máquinas virtuais locais.

  • Custo e benefícios de armazenamento ilimitados: Esse recurso permite que você tenha um armazenamento fora do site ilimitado no Azure, aproveitando os recursos de computação locais. Ao usar o Azure como um local de armazenamento, você pode se concentrar facilmente na lógica do aplicativo sem a sobrecarga do gerenciamento de hardware. Se você perder um nó de computação local, poderá configurar um novo sem nenhuma movimentação de dados.

  • Benefícios de alta disponibilidade e recuperação de desastre: Usar arquivos de dados do SQL Server no recurso do Azure pode simplificar as soluções de alta disponibilidade e recuperação de desastre. Por exemplo, se uma máquina virtual no Azure ou uma instância do SQL Server falhar, você poderá recriar seus bancos de dados em um novo computador apenas restabelecendo links para Blobs do Azure.

  • Benefícios de segurança: Esse novo aprimoramento permite separar uma instância de computação de uma instância de armazenamento. Você pode ter um banco de dados totalmente criptografado com descriptografia ocorrendo apenas na instância de computação, mas não em uma instância de armazenamento. Em outras palavras, usando esse novo aprimoramento, você pode criptografar todos os dados na nuvem pública usando certificados TDE (Transparent Data Encryption), que são fisicamente separados dos dados. As chaves TDE podem ser armazenadas no banco de dados mestre, que é armazenado localmente em sua máquina fisicamente segura no local e tem backup feito localmente. Você pode usar essas chaves locais para criptografar os dados, que residem no Armazenamento do Azure. Se suas credenciais de conta de armazenamento em nuvem forem roubadas, seus dados ainda permanecerão seguros, pois os certificados TDE sempre residem no local.

Conceitos e requisitos

Conceitos de Armazenamento do Azure

Ao usar os Arquivos de Dados do SQL Server no recurso do Azure, você precisa criar uma conta de armazenamento e um contêiner no Azure. Em seguida, você precisa criar uma credencial do SQL Server, que inclui informações sobre a política do contêiner, bem como uma assinatura de acesso compartilhado necessária para acessar o contêiner.

No Azure, uma conta de armazenamento representa o nível mais alto do namespace para acessar Blobs. Uma conta de armazenamento pode conter um número ilimitado de contêineres, desde que seu tamanho total seja inferior a 500 TB. Para obter as informações mais recentes sobre os limites de armazenamento, consulte a Assinatura do Azure e limites de serviço, cotas e restrições. Um contêiner fornece um agrupamento de um conjunto de Blobs. Todos os Blobs devem estar em um contêiner. Uma conta pode conter um número ilimitado de contêineres. Da mesma forma, um contêiner também pode armazenar um número ilimitado de Blobs. Há dois tipos de blobs que podem ser armazenados no Armazenamento do Azure: blobs de blocos e páginas. Esse novo recurso usa blobs de página, que podem ter até 1 TB de tamanho e são mais eficientes quando intervalos de bytes em um arquivo são modificados com frequência. Você pode acessar Blobs usando o seguinte formato de URL: http://storageaccount.blob.core.windows.net/<container>/<blob>.

Considerações sobre cobrança do Azure

Estimar o custo do uso dos Serviços do Azure é uma questão importante no processo de tomada de decisão e planejamento. Ao armazenar arquivos de dados do SQL Server no Armazenamento do Azure, você precisa pagar os custos associados ao armazenamento e às transações. Além disso, a implementação dos Arquivos de Dados do SQL Server no recurso de Armazenamento do Azure requer uma renovação da concessão de Blob a cada 45 a 60 segundos implicitamente. Isso também resulta em custos de transação por arquivo de banco de dados, como .mdf ou .ldf. Com base em nossas estimativas, o custo de renovação de concessões para dois arquivos de banco de dados (.mdf e .ldf) seria de cerca de 2 centavos por mês de acordo com o modelo de preços atual. Recomendamos que você use as informações na página Preços do Azure para ajudar a estimar os custos mensais associados ao uso do Armazenamento do Azure e das Máquinas Virtuais do Azure.

Conceitos do SQL Server

Ao usar esse novo aprimoramento, você precisará fazer o seguinte:

  • Você deve criar uma política em um contêiner e também gerar uma chave SAS (assinatura de acesso compartilhado).

  • Para cada contêiner usado por um arquivo de log ou dados, você deve criar uma Credencial do SQL Server cujo nome corresponde ao caminho do contêiner.

  • Você deve armazenar as informações sobre o contêiner do Armazenamento do Azure, seu nome de política associado e a chave SAS no repositório de credenciais do SQL Server.

O exemplo a seguir pressupõe que um contêiner do Armazenamento do Azure foi criado e uma política foi criada com direitos de leitura, gravação, lista. A criação de uma política em um contêiner gera uma chave SAS que é segura para manter não criptografada na memória e necessária pelo SQL Server para acessar os arquivos de blob no contêiner. No snippet de código a seguir, substitua 'your SAS key' por uma entrada semelhante à seguinte: 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'. Para obter mais informações, consulte Criar e usar uma assinatura de acesso compartilhado

-- Create a credential  
CREATE CREDENTIAL [https://testdb.blob.core.windows.net/data]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = 'your SAS key'  
  
-- Create database with data and log files in Azure container.  
CREATE DATABASE testdb   
ON  
( NAME = testdb_dat,  
    FILENAME = 'https://testdb.blob.core.windows.net/data/TestData.mdf' )  
 LOG ON  
( NAME = testdb_log,  
    FILENAME =  'https://testdb.blob.core.windows.net/data/TestLog.ldf')

Importante

Se houver referências ativas a arquivos de dados em um contêiner, as tentativas de excluir a credencial correspondente do SQL Server falharão.

Segurança

Veja a seguir considerações e requisitos de segurança ao armazenar arquivos de dados do SQL Server no Armazenamento do Azure.

  • Ao criar um contêiner para o serviço de Armazenamento de Blobs do Azure, recomendamos que você defina o acesso como privado. Quando você define o acesso a dados privados, contêineres e blobs podem ser lidos apenas pelo proprietário da conta do Azure.

  • Ao armazenar arquivos de banco de dados do SQL Server no Armazenamento do Azure, você precisa usar uma assinatura de acesso compartilhado, um URI que concede direitos de acesso restritos a contêineres, blobs, filas e tabelas. Usando uma assinatura de acesso compartilhado, você pode permitir que o SQL Server acesse recursos em sua conta de armazenamento sem compartilhar sua chave de conta de armazenamento do Azure.

  • Além disso, recomendamos que você continue implementando as práticas tradicionais de segurança local para seus bancos de dados.

Pré-requisitos de Instalação

Veja a seguir os pré-requisitos de instalação ao armazenar arquivos de dados do SQL Server no Azuree.

  • SQL Server local: A versão do SQL Server 2014 inclui esse recurso. Para saber como baixar o SQL Server 2014, consulte o SQL Server 2014.

  • SQL Server em execução em uma máquina virtual do Azure: se você estiver instalando o SQL Server em uma Máquina Virtual do Azure, instale o SQL Server 2014 ou atualize sua instância existente. Da mesma forma, você também pode criar uma nova máquina virtual no Azure usando a imagem da plataforma SQL Server 2014. Para saber como baixar o SQL Server 2014, consulte o SQL Server 2014.

Limitações

  • Na versão atual desse recurso, não há suporte para armazenar FileStream dados no Armazenamento do Azure. Você pode armazenar Filestream dados em um banco de dados local integrado do Armazenamento do Azure, mas não pode mover dados de fluxo de arquivos entre computadores usando o Armazenamento do Azure. Para dados de FileStream, recomendamos que você continue usando as técnicas tradicionais para mover os arquivos (.mdf, .ldf) associados ao Filestream entre diferentes máquinas.

  • Atualmente, esse novo aprimoramento não dá suporte a mais de uma instância do SQL Server que acessa os mesmos arquivos de banco de dados no Armazenamento do Azure ao mesmo tempo. Se o ServerA estiver online com um arquivo de banco de dados ativo e se o ServerB for iniciado acidentalmente e ele também tiver um banco de dados que aponte para o mesmo arquivo de dados, o segundo servidor não iniciará o banco de dados com um código de erro 5120 Não é possível abrir o arquivo físico "%.*ls". Erro do sistema operacional %d: "%ls".

  • Somente arquivos .mdf, .ldf e .ndf podem ser armazenados no Armazenamento do Azure usando os Arquivos de Dados do SQL Server no recurso do Azure.

  • Ao usar os Arquivos de Dados do SQL Server no recurso do Azure, não há suporte para replicação geográfica para sua conta de armazenamento. Se uma conta de armazenamento for replicada geograficamente e ocorrer um failover geográfico, poderá ocorrer corrupção de banco de dados.

  • Cada Blob pode ter até 1 TB de tamanho máximo. Isso cria um limite superior em dados de banco de dados individuais e arquivos de log que podem ser armazenados no Armazenamento do Azure.

  • Não é possível armazenar In-Memory dados OLTP no Blob do Azure usando os Arquivos de Dados do SQL Server no recurso de Armazenamento do Azure. Isso ocorre porque In-Memory OLTP tem uma dependência FileStream e, na versão atual desse recurso, não há suporte para armazenar FileStream dados no Armazenamento do Azure.

  • Ao usar a funcionalidade de Arquivos de Dados do SQL Server no Azure, o SQL Server executa todas as comparações de URL ou caminho de arquivo usando o conjunto de ordenação no banco de dados master.

  • AlwaysOn Availability Groups há suporte desde que você não adicione novos arquivos de banco de dados ao banco de dados primário. Se uma operação de banco de dados exigir que um novo arquivo seja criado no banco de dados primário, primeiro desabilite os Grupos de Disponibilidade AlwaysOn no nó secundário. Em seguida, execute a operação de banco de dados no banco de dados primário e faça backup do banco de dados no nó primário. Em seguida, restaure o banco de dados para o nó secundário e habilite os Grupos de Disponibilidade AlwaysOn no nó secundário. Observe que não há suporte para Instâncias de Cluster de Failover AlwaysOn ao usar os Arquivos de Dados do SQL Server no recurso do Azure.

  • Durante a operação normal, o SQL Server usa concessões temporárias para reservar Blobs para armazenamento com uma renovação de cada concessão de Blob a cada 45 a 60 segundos. Se um servidor falhar e outra instância do SQL Server configurada para usar os mesmos blobs for iniciada, a nova instância aguardará até 60 segundos para que a concessão existente no Blob expire. Se você quiser anexar o banco de dados a outra instância e não puder esperar que a concessão expire dentro de 60 segundos, poderá interromper explicitamente a concessão no Blob para evitar falhas nas operações de anexação.

Suporte a ferramentas e referência de programação

Esta seção descreve quais ferramentas e bibliotecas de referência de programação podem ser usadas ao armazenar arquivos de dados do SQL Server no Armazenamento do Azure.

Suporte do PowerShell

No SQL Server 2014, você pode usar cmdlets do PowerShell para armazenar arquivos de dados do SQL Server no serviço de Armazenamento de Blobs do Azure fazendo referência a um caminho de URL de Armazenamento de Blobs em vez de um caminho de arquivo. Você pode acessar Blobs usando o seguinte formato: http://storageaccount.blob.core.windows.net/<container>/<blob> de URL.

Suporte a objetos e contadores de desempenho do SQL Server

A partir do SQL Server 2014, um novo objeto do SQL Server foi adicionado para ser usado com arquivos de dados do SQL Server no recurso de Armazenamento do Azure. O novo objeto do SQL Server é chamado de SQL Server, HTTP_STORAGE_OBJECT e pode ser usado pelo Monitor do Sistema para monitorar a atividade ao executar o SQL Server com o Armazenamento do Azure.

Suporte ao SQL Server Management Studio

O SQL Server Management Studio permite que você use esse recurso por meio de várias janelas de diálogo. Por exemplo, você pode digitar o caminho de URL do contêiner de armazenamento, como https://teststorageaccnt.blob.core.windows.net/testcontainer/ um caminho em várias janelas de diálogo, como Novo Banco de Dados, Anexar Banco de Dados e Restaurar Banco de Dados. Para obter mais informações, consulte Tutorial: Arquivos de Dados do SQL Server no serviço de Armazenamento do Azure.

Suporte a objetos de gerenciamento do SQL Server

Ao usar os Arquivos de Dados do SQL Server no recurso do Azure, todos os SMO (Objetos de Gerenciamento do SQL Server) têm suporte. Se um objeto SMO exigir um caminho de arquivo, use o formato de URL do BLOB em vez de um caminho de arquivo local, como https://teststorageaccnt.blob.core.windows.net/testcontainer/. Para obter mais informações sobre o SMO (SQL Server Management Objects), consulte o Guia de Programação do SMO (SQL Server Management Objects) nos Manuais Online do SQL Server.

Suporte Transact-SQL

Este novo recurso introduziu a seguinte alteração na área de superfície Transact-SQL:

  • Uma nova coluna int, credential_id, na visão do sistema sys.master_files. A coluna credential_id é usada para possibilitar que os arquivos de dados com suporte ao Armazenamento do Azure sejam referenciados de volta a sys.credentials para as credenciais criadas para eles. Você pode usá-lo para solução de problemas, como quando uma credencial não pode ser excluída porque há um arquivo de banco de dados que a utiliza.

Solução de problemas para arquivos de dados do SQL Server no Azure

Para evitar erros devido a recursos ou limitações sem suporte, primeiro examine limitações.

A lista de erros que você pode obter ao usar os Arquivos de Dados do SQL Server no recurso de Armazenamento do Azure é a seguinte.

Erros de autenticação

  • Não é possível descartar a credencial '%.*ls' porque ela é usada por um arquivo de banco de dados ativo.
    Resolução: você pode ver esse erro ao tentar remover uma credencial que ainda está sendo usada por um arquivo de banco de dados ativo no Armazenamento do Azure. Para remover a credencial, primeiro você deve excluir o blob associado que tem esse arquivo de banco de dados. Para excluir um blob que tenha uma concessão ativa, primeiro você deve interromper a concessão.

  • A Assinatura de Acesso Compartilhado não foi criada no contêiner corretamente.
    Resolução: verifique se você criou uma Assinatura de Acesso Compartilhado no contêiner corretamente. Examine as instruções fornecidas na Lição 2 no Tutorial: Arquivos de Dados do SQL Server no serviço de Armazenamento do Azure.

  • A credencial do SQL Server não foi criada corretamente.
    Resolução: verifique se você usou a 'Assinatura de Acesso Compartilhado' para o campo Identidade e criou um segredo corretamente. Examine as instruções fornecidas na Lição 3 no Tutorial: Arquivos de Dados do SQL Server no serviço de Armazenamento do Azure.

Erros de blob de concessão:

  • Errou ao tentar iniciar o SQL Server após outra instância usando os mesmos arquivos de blob ter falhado. Resolução: Durante a operação normal, o SQL Server usa permissões temporárias para reservar Blobs para armazenamento, com a renovação de cada permissão de Blob a cada 45 a 60 segundos. Se um servidor falhar e outra instância do SQL Server configurada para usar os mesmos blobs for iniciada, a nova instância aguardará até 60 segundos para que a concessão existente no Blob expire. Se você quiser anexar o banco de dados a outra instância e não puder esperar que a concessão expire dentro de 60 segundos, poderá interromper explicitamente a concessão no Blob para evitar falhas nas operações de anexação.

Erros de banco de dados

  1. Erros ao criar um banco de dados
    Resolução: revise as instruções dadas na Lição 4 no Tutorial: Arquivos de Dados do SQL Server no serviço de Armazenamento do Azure.

  2. Erros ao executar a instrução Alter
    Resolução: execute a instrução Alter Database quando o banco de dados estiver online. Ao copiar os arquivos de dados para o Armazenamento do Azure, sempre crie um blob de páginas e não um blob de blocos. Caso contrário, o Banco de Dados ALTER falhará. Examine as instruções fornecidas na Lição 7 no Tutorial: Arquivos de Dados do SQL Server no serviço de Armazenamento do Azure.

  3. Código de erro 5120 Não é possível abrir o arquivo físico "%.*ls". Erro do sistema operacional %d: "%ls"
    Resolução: atualmente, esse novo aprimoramento não dá suporte a mais de uma instância do SQL Server que acessa os mesmos arquivos de banco de dados no Armazenamento do Azure ao mesmo tempo. Se o ServerA estiver online com um arquivo de banco de dados ativo e se o ServerB for iniciado acidentalmente e ele também tiver um banco de dados que aponte para o mesmo arquivo de dados, o segundo servidor não iniciará o banco de dados com um código de erro 5120 Não é possível abrir o arquivo físico "%.*ls". Erro do sistema operacional %d: "%ls".

    Para resolver esse problema, primeiro determine se você precisa do ServerA para acessar o arquivo de banco de dados no Armazenamento do Azure ou não. Caso contrário, basta remover qualquer conexão entre o ServerA e os arquivos de banco de dados no Armazenamento do Azure. Para fazer isso, siga estas etapas:

    1. Defina o caminho do arquivo do Servidor A para uma pasta local usando a instrução ALTER Database.

    2. Defina o banco de dados offline no Servidor A.

    3. Em seguida, copie arquivos de banco de dados do Armazenamento do Azure para a pasta local no Servidor A. Isso garante que o ServerA ainda tenha uma cópia do banco de dados localmente.

    4. Defina o banco de dados online.

Consulte Também

Tutorial: Arquivos de Dados do SQL Server no serviço de Armazenamento do Azure

  • Last updated on