Ficheiros de dados SQL Server em Microsoft Azure

Aplica-se a:SQL Server

O SQL Server Data Files no Microsoft Azure permite o suporte nativo para ficheiros de base de dados SQL Server armazenados como blobs. Permite-lhe criar uma base de dados no SQL Server a correr on-premises ou numa máquina virtual no Microsoft Azure com um local de armazenamento dedicado para os seus dados no Microsoft Azure Blob storage. Também simplifica o processo de mover bases de dados entre máquinas. Podes separar bases de dados de uma máquina e ligá-las a outra. Além disso, fornece um local alternativo de armazenamento para os ficheiros de backup da sua base de dados, permitindo restaurar a partir ou para o Microsoft Azure Storage. Assim, permite várias soluções híbridas ao proporcionar vários benefícios para virtualização de dados, movimentação de dados, segurança e disponibilidade, bem como para custos e manutenção simples e baixos para alta disponibilidade e escalabilidade elástica.

Este artigo apresenta conceitos e considerações que são centrais para armazenar ficheiros de dados SQL Server no Microsoft Azure Storage Service.

Para uma experiência prática sobre como usar esta funcionalidade, consulte o Tutorial: Utilização do Microsoft Azure Blob Storage com bases de dados SQL Server.

Porque usar ficheiros de dados SQL Server no Microsoft Azure?

• Benefícios de migração fácil e rápida: Esta funcionalidade simplifica o processo de migração ao mover uma base de dados de cada vez entre máquinas on-premises e entre ambientes on-premises e cloud, sem quaisquer alterações na aplicação. Assim, suporta uma migração incremental mantendo a infraestrutura local existente em funcionamento. Além disso, ter acesso a um armazenamento centralizado de dados simplifica a lógica da aplicação quando uma aplicação precisa de correr em múltiplos locais num ambiente local. Em alguns casos, poderá ser necessário instalar rapidamente centros informáticos em locais geograficamente dispersos, que recolhem dados de várias fontes diferentes. Com o Azure Data Files, em vez de mover dados de um local para outro, pode armazenar muitas bases de dados como blobs de páginas Microsoft Azure e depois executar scripts Transact-SQL para criar bases de dados nas máquinas locais ou máquinas virtuais.

• Custos e benefícios de armazenamento ilimitado: Esta funcionalidade permite-lhe ter armazenamento ilimitado fora do local no Microsoft Azure, aproveitando os recursos de computação local. Quando usa o Microsoft Azure como local de armazenamento, pode facilmente focar-se na lógica da aplicação sem a sobrecarga da gestão de hardware. Se perder um nó de computação no local, pode configurar um novo sem qualquer movimento de dados.

• Alta disponibilidade e benefícios de recuperação de desastres: Utilizar ficheiros de dados SQL Server na funcionalidade Microsoft Azure pode simplificar as soluções de alta disponibilidade e recuperação de desastres. Por exemplo, se uma máquina virtual no Microsoft Azure ou uma instância de SQL Server falhar, pode recriar as suas bases de dados numa nova instância SQL Server apenas restabelecendo ligações aos blobs.

• Benefícios de segurança: Com ficheiros de dados SQL Server no Azure, podes separar uma instância de computação de uma instância de armazenamento. Pode ter uma base de dados totalmente encriptada, com a desencriptação a ocorrer apenas na instância de computação, mas não numa instância de armazenamento. Por outras palavras, pode encriptar todos os dados na cloud pública usando certificados de Encriptação Transparente de Dados (TDE), que estão fisicamente separados dos dados. As chaves TDE podem ser armazenadas na master base de dados, que fica localmente no seu computador fisicamente seguro e é copiada localmente. Pode usar estas chaves locais para encriptar os dados, que residem no Microsoft Azure Storage. Se as credenciais da sua conta de armazenamento na cloud forem roubadas, os seus dados continuam seguros, pois os certificados TDE residem sempre nas instalações.

• Cópia de segurança instantânea: Esta funcionalidade permite-lhe usar snapshots Azure para fornecer backups quase instantâneos e restauros mais rápidos dos ficheiros de base de dados armazenados usando o Azure Blob Storage. Esse recurso permite simplificar suas políticas de backup e restauração. Para obter mais informações, consulte File-Snapshot Backups para arquivos de banco de dados no Azure.

Conceitos e Requisitos

Os discos Azure são compatíveis com soluções empresariais de continuidade de negócios e recuperação de desastres. Se armazenar as suas bases de dados diretamente em blobs, ou nos Azure Premium Files, os dados não são automaticamente associados à sua VM para infraestrutura, gestão e monitorização.

Colocar os ficheiros da base de dados em blobs de página é uma funcionalidade mais avançada do que usar discos Azure, que são simples e fáceis de usar.

A orientação básica é usar Discos do Azure, a menos que tenha um cenário em que precise mesmo de evitar criar uma cópia dos dados para backups, ou de restaurar como uma operação proporcional ao tamanho dos dados. Para alta disponibilidade e recuperação de desastres, usar backup regular para URL ou backup gerido para armazenamento de Blobs também é muito mais vantajoso do que snapshots de ficheiros, uma vez que oferece gestão do ciclo de vida, suporte multi-região, soft delete e todas as outras funcionalidades do armazenamento de Blobs para os seus backups.

Conceitos de Armazenamento do Azure

Ao usar a funcionalidade SQL Server Data Files no Azure, é necessário criar uma conta de armazenamento e um contentor no Azure. Depois, precisa de criar uma credencial SQL Server, que inclui informações sobre a política do contentor, bem como uma assinatura de acesso partilhada necessária para aceder ao contentor.

No Microsoft Azure, uma conta de armazenamento Azure representa o nível mais alto do namespace para aceder a blobs. Uma conta de armazenamento pode conter um número ilimitado de contentores, desde que o seu tamanho total esteja abaixo dos limites de armazenamento. Para informações mais recentes sobre limites de armazenamento, consulte Azure Subscrição e Limites de Serviços, Quotas e Restrições. Um contentor 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 contentores. De forma semelhante, um contentor pode armazenar um número ilimitado de blobs.

Existem dois tipos de blobs que podem ser armazenados no Azure Storage: blobs de bloco e blobs de página. Esta funcionalidade utiliza blobs de página, que são mais eficientes quando intervalos de bytes num ficheiro são modificados frequentemente. Pode aceder a blobs usando o seguinte formato URL: https://storageaccount.blob.core.windows.net/<container>/<blob>.

Considerações de faturação do Azure

Estimar o custo de utilizar os Serviços Azure é uma questão importante no processo de tomada de decisão e planeamento. Ao armazenar ficheiros de dados SQL Server no Azure Storage, é necessário pagar custos associados ao armazenamento e transações. Além disso, a implementação da funcionalidade SQL Server Data Files no Azure Storage requer uma renovação do arrendamento de blob a cada 45 a 60 segundos implicitamente. Isto também resulta em custos de transação por ficheiro de base de dados, como .mdf ou .ldf. Use a informação na página de Preços Azure para ajudar a estimar os custos mensais associados à utilização do Azure Storage e das Máquinas Virtuais Azure.

Conceitos do SQL Server

Para usar blobs de página do Azure para ficheiros de dados do SQL Server:

• Crie uma política num contentor e também gere uma assinatura de acesso partilhado (SAS).

• Para cada contentor usado por um dado ou um ficheiro de registo, crie-se uma credencial SQL Server cujo nome corresponda ao caminho do contentor.

• Armazene a informação relativa ao contentor do Azure Storage, o nome da sua política associada e a chave SAS na loja de credenciais do SQL Server.

O exemplo seguinte assume que foi criado um contentor de armazenamento Azure e que foi criada uma política com direitos de leitura, escrita e lista. Criar uma política num contentor gera uma chave SAS, que é segura para manter sem encriptação na memória e necessária pelo SQL Server para aceder aos ficheiros blob no contentor.

No trecho de código a seguir, substitua '<your SAS key>' pela chave SAS. A chave SAS ficará 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>' assim.

CREATE CREDENTIAL [https://testdb.blob.core.windows.net/data]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = '<your SAS key>'  
  
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')  

Para mais informações, consulte Gerir o Acesso a Recursos de Armazenamento Azure

Segurança

Seguem-se as considerações e requisitos de segurança ao armazenar ficheiros de dados SQL Server no Azure Storage.

• Ao criar um contentor para o Azure Blob Storage, recomendamos que defina o acesso como privado. Quando definir o acesso como privado, os dados de contentores e blobs podem ser lidos apenas pelo dono da conta Azure.

• Ao armazenar ficheiros de base de dados SQL Server no Azure Storage, é necessário usar uma assinatura de acesso partilhada, um URI que concede direitos de acesso restritos a contentores, blobs, filas e tabelas. Ao usar uma assinatura de acesso partilhada, pode permitir que o SQL Server aceda a recursos na sua conta de armazenamento sem partilhar a chave da sua conta de armazenamento Azure.

• Além disso, recomendamos que continue a implementar as práticas tradicionais de segurança local para as suas bases de dados.

Pré-requisitos de instalação

Os seguintes são os pré-requisitos de instalação ao armazenar ficheiros de dados SQL Server no Azure.

• SQL Server on-premises: O SQL Server 2016 e posteriores incluem esta funcionalidade. Para saber como descarregar a versão mais recente do SQL Server, consulte SQL Server.

• SQL Server a correr numa máquina virtual Azure: Se estiver a instalar SQL Server numa máquina virtual Azure, instale o SQL Server 2016 ou atualize a sua instância existente. De forma semelhante, também pode criar uma nova máquina virtual no Azure usando a imagem da plataforma SQL Server 2016.

Limitações

• Devido às características de desempenho das cargas de trabalho SQL Server, os ficheiros de dados SQL Server são implementados como blobs de página no Azure Blob Storage. Outros tipos de armazenamento de blobs, como blobs de bloco ou Azure Data Lake Storage , não são suportados.

• Na versão atual desta funcionalidade, não é suportado armazenar dados FileStream no Azure Storage. Pode armazenar dados FileStream numa base de dados que também contenha ficheiros de dados armazenados no Azure Storage, mas todos os ficheiros de dados FileStream devem ser armazenados em armazenamento local. Como os dados do FileStream têm de residir em armazenamento local, não podem ser movidos entre máquinas usando o Azure Storage, por isso recomendamos que continue a usar as técnicas tradicionais para mover os dados associados ao FileStream entre diferentes máquinas.

• Atualmente, apenas uma instância do SQL Server pode aceder a um determinado ficheiro de base de dados no Azure Storage de cada vez. Se a Instância A estiver online com um ficheiro de base de dados ativo e se a Instância B for iniciada acidentalmente, e também tiver uma base de dados que aponta para o mesmo ficheiro de dados, a segunda instância falhará ao iniciar a base de dados com um código 5120 Unable to open the physical file "%.\*ls". Operating system error %d: "%ls"de erro .

• Apenas ficheiros .mdf, .ldf e .ndf podem ser armazenados no Azure Storage utilizando a funcionalidade SQL Server Data Files in Azure.

• Ao usar a funcionalidade SQL Server Data Files no Azure, a geo-replicação da sua conta de armazenamento não é suportada. Se uma conta de armazenamento for geo-replicada e ocorrer um geo-failover, pode ocorrer corrupção da base de dados.

• Para limitações de capacidade, veja Introdução ao armazenamento em blob.

• Não é possível armazenar dados OLTP In-Memory no armazenamento de Blobs usando a funcionalidade de Ficheiros de Dados do SQL Server no Armazenamento Azure. Isto deve-se ao facto de In-Memory OLTP depender do FileStream e, na versão atual desta funcionalidade, armazenar dados do FileStream no Azure Storage não é suportado.

• Ao utilizar a funcionalidade Ficheiros de Dados do SQL Server no Azure, o SQL Server realiza todas as comparações de URLs ou caminhos de ficheiro usando a colação definida na base de dados master.

• Os grupos de disponibilidade Always On são suportados desde que não adicione novos ficheiros de base de dados à base de dados na réplica principal. Se uma operação de base de dados exigir a criação de um novo ficheiro na base de dados na réplica primária, desative primeiro os grupos de disponibilidade no nó secundário. Depois, realiza a operação na base de dados e efetua o backup na réplica principal. De seguida, restaure a base de dados para a réplica secundária. Depois de terminar, reative os grupos de disponibilidade do Always On no nó secundário.

  Observação

  As instâncias de cluster de failover Always On não são suportadas quando se utiliza a funcionalidade de dados SQL Server no Azure.

• Durante o funcionamento normal, o SQL Server utiliza arrendamentos temporários para reservar blobs para armazenamento, renovando cada arrendamento de blobs 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 pela expiração da concessão existente no blob. Se quiseres ligar a base de dados a outra instância e não puderes esperar que o contrato expire dentro de 60 segundos, podes libertar explicitamente o arrendamento no blob.

Ferramentas e suporte de referência de programação

Esta secção descreve que ferramentas e bibliotecas de referência de programação podem ser usadas ao armazenar ficheiros de dados SQL Server no Azure Storage.

Suporte do PowerShell

Use cmdlets do PowerShell para armazenar ficheiros de dados do SQL Server no serviço de armazenamento Blob, referenciando um caminho URL de armazenamento Blob em vez de um caminho de ficheiro. Aceder a blobs usando o seguinte formato URL: https://storageaccount.blob.core.windows.net/<container>/<blob>.

Suporte a objetos e contadores de desempenho do SQL Server

A partir do SQL Server 2014, foi adicionado um novo objeto SQL Server para ser utilizado com a funcionalidade SQL Server Data Files in Azure Storage. O novo objeto SQL Server chama-se SQL Server, HTTP_STORAGE_OBJECT e pode ser usado pelo System Monitor para monitorizar a atividade ao executar SQL Server com Azure Storage.

Suporte ao SQL Server Management Studio

O SQL Server Management Studio permite-lhe usar esta funcionalidade através de várias janelas de diálogo. Por exemplo, https://teststorageaccnt.blob.core.windows.net/testcontainer/ representa o caminho URL de um contentor de armazenamento. Pode ver este Caminho em várias janelas de diálogo, como Nova Base de Dados, Anexar Base de Dados e Restaurar Base de Dados. Para mais informações, veja Tutorial: Usar Azure Blob Storage com bases de dados SQL Server.

Suporte para Objetos de Gestão do SQL Server (SMO)

Ao utilizar a funcionalidade SQL Server Data Files no Azure, todos os SQL Server Management Objects (SMO) são suportados. Se um objeto SMO requer um caminho de ficheiro, use o formato URL BLOB em vez de um caminho local, como https://teststorageaccnt.blob.core.windows.net/testcontainer/. Para mais informações sobre os SQL Server Management Objects (SMO), consulte o Guia de Programação dos SQL Server Management Objects (SMO ) no SQL Server Books Online.

Transact-SQL suporte

A adição desta funcionalidade introduziu a seguinte alteração na área de superfície Transact-SQL:

• Uma nova coluna int , credential_id, na sys.master_files vista do sistema. A coluna credential_id é utilizada para permitir que os ficheiros de dados do Azure Storage sejam referenciados de volta a sys.credentials para as credenciais criadas para eles. Pode usá-lo para resolução de problemas, como uma credencial que não pode ser apagada quando há um ficheiro de base de dados a usá-la.

Resolução de Problemas para Ficheiros de Dados do SQL Server na Microsoft Azure

Para evitar erros devido a funcionalidades ou limitações não suportadas, reveja primeiro as Limitações.

A lista de erros que pode ter ao usar a funcionalidade SQL Server Data Files no Azure Storage é a seguinte.

Erros de autenticação

• Não é possível eliminar a credencial '%.*ls' porque é usada por um ficheiro de base de dados ativo.
  Resolução: Pode ver este erro quando tenta eliminar uma credencial que ainda está a ser usada por um ficheiro de base de dados ativo no Azure Storage. Para eliminar a credencial, primeiro deve eliminar o blob associado que contém o ficheiro da base de dados. Para eliminar um blob que tenha um contrato de arrendamento ativo, deve primeiro libertar o contrato.

• A assinatura de acesso partilhada não foi criada corretamente no contentor.
  Resolução: Certifique-se de que criou corretamente uma Assinatura de Acesso Partilhada no contentor. Revê as instruções dadas na Lição 2 do Tutorial: Usa o Azure Blob Storage com bases de dados SQL Server.

• A credencial do SQL Server não foi criada corretamente.
  Resolução: Certifique-se de que usou 'Assinatura de Acesso Partilhada' para o campo Identidade e criou corretamente um segredo. Revise as instruções dadas na Lição 3 do Tutorial: Use Azure Blob Storage com bases de dados SQL Server.

Erros de blob de locação:

• Erro ao tentar iniciar o SQL Server depois de outra instância com os mesmos ficheiros blob ter crashado. Resolução: Durante o funcionamento normal, o SQL Server utiliza arrendamentos temporários para reservar blobs para armazenamento, renovando cada arrendamento de blob a cada 45 a 60 segundos. Se um servidor crashar e outra instância do SQL Server configurada para usar os mesmos blobs for iniciada, a nova instância aguardará até 60 segundos até que o arrendamento existente do blob expire. Se quiser anexar a base de dados a outra instância e não puder esperar que o arrendamento expire em 60 segundos, pode libertar explicitamente o arrendamento no blob para evitar falhas nas operações de anexação.

Erros na base de dados

Erros ao criar uma base de dados Resolução: Rever as instruções dadas na Lição 4 do Tutorial: Usar o Microsoft Azure Blob Storage com bases de dados SQL Server.

Erros ao executar a instrução Alter Resolução: Certifique-se de executar a instrução Alter Database quando a base de dados estiver online. Ao copiar os ficheiros de dados para o Azure Storage, crie sempre um blob de página e não um blob de blocos. Caso contrário, a base de dados ALTER falhará. Revise as instruções dadas na Lição 7 do Tutorial: Use o Microsoft Azure Blob Storage com bases de dados SQL Server.

Código de erro - 5120 Não é possível abrir o ficheiro físico "%.*ls". Erro de sistema operacional %d: "%ls"

Resolução: Esta funcionalidade não suporta mais do que uma instância do SQL Server para aceder aos mesmos ficheiros de base de dados no Azure Storage ao mesmo tempo. Se a Instância A estiver online com um ficheiro de base de dados ativo e se a Instância B for iniciada, e também tiver uma base de dados que aponta para o mesmo ficheiro de dados, a segunda instância falhará ao iniciar a base de dados com um código 5120 Unable to open the physical file "%.\*ls". Operating system error %d: "%ls"de erro .

Para resolver este problema, primeiro determine se precisa do ServerA para aceder ao ficheiro da base de dados no Azure Storage ou não. Se não, remova qualquer ligação entre a InstanceA e os ficheiros da base de dados no Azure Storage. Para o fazer, siga estes passos:

1. Defina o caminho do ficheiro da InstanceA para uma pasta local usando a instrução ALTER Database.

2. Defina a base de dados offline no InstanceA.

3. Depois, copie ficheiros de base de dados do Azure Storage para a pasta local na InstanceA. Isto garante que a InstanceA ainda tem uma cópia da base de dados localmente.

4. Coloque a base de dados online.

Código de erro 833 - Pedidos de E/S a demorar mais de 15 segundos a ser concluídos

Este erro indica que o sistema de armazenamento não consegue satisfazer as exigências da carga de trabalho do SQL Server. Ou diminui a atividade de IO na camada de aplicação, ou aumenta a capacidade de throughput na camada de armazenamento. Para saber mais, consulte o Erro 833. Se persistirem problemas de desempenho, considere mover ficheiros para outro nível de armazenamento, como Premium ou UltraSSD. Para o SQL Server em VMs no Azure, consulte otimização do desempenho de armazenamento.

Próximos passos

• Criar uma base de dados