Categorias
Azure SQL Database How To Virtual PASS BR

Azure SQL Database – Migration tools – part 3

[bing_translator]

Um outro metodo para migração de um database para o Azure SQL Database é através do uso de replicação. Não é o meu método favorito nem o tópico que eu mais gosto, na verdade eu evito o uso de replicação, porem esse tipo de migração pode ser útil em vários cenários.

Transactional Replication

Esse processo tem algumas particularidades como por exemplo:

  • Menor downtime
  • Perfeito para databases grandes
  • Suportado a partir do SQL Server 2012
  • Processo em múltiplos passos independentes
  • Requer chaves primarias em cada tabela presente no Publisher
  • Maior complexidade
  • Custos adicionais (setup distribution database, publisher e subscriber)
  • Exige mais conhecimento do DBA

Não esquece de validar se seu database está pronto para o Azure SQL Database através do Data Migration Assistant – Assessment

Configurar a replicação transacional para o Azure SQL Server não é nem um pouco diferente de configurar qualquer outro tipo de replicação para um servidor on-premise. Primeiro passo é criar um database vazio no Azure SQL Database pois é necessário que o database já exista para configurar a replicação.

Encontrei esse vídeo no channel9 explicando o passo a passo para utilizar a replicação transacional.
Para saber mais de como criar um Publisher utilizando replicação transacional acesse esse link.
Existem considerações que devemos ter e o time de suporte do Azure SQL Database descreve muito bem essas considerações nesse post.
O time do SQLCAT – SQL Server  Custumer Advisor Team também descreve como realizar esse procedimento nesse post.
Nesse outro link você pode ler sobre as restrições.

GO-NO-GO

Por ser um método que permite menor downtime existem alguns passos que devemos realizar:

  • Pare a aplicação e qualquer acesso que o database possa receber (Pacotes SSIS, integrações e etc.)
  • Monitore a replicação para que esteja completamente sincronizada
  • Reconfigure as connections strings (Aplicação, Pacotes SSIS, integrações e etc.)
  • Verifique se a aplicação está funcionando
  • Em caso de sucesso, exclua a replicação

 

Como eu disse, esse é um método extremamente complexo e trabalhoso, mas perfeitamente plausível para aplicações com downtime curtos.

Categorias
Azure SQL Database How To Virtual PASS BR

Azure SQL Database – Migration tools – part 2

[bing_translator]

Existem algumas ferramentas que ajudam a migrar seu database para o Azure SQL Database e eu já falei de algumas:

Export e Import manualmente

Mais uma vez o SQL Server Management Studio (SSMS) é a ferramenta que pode ser usada através do Export Data-tier Application.
Esse processo tem algumas diferenças quando comparado com o Migration Wizard

  • Suporta qualquer database a partir da versão SQL Server 2005
  • Excelente para database de tamanho pequeno, médio ou grande
  • .bacpad pode ser armazenado no Azure Storage ou localmente
  • Processo em múltiplos passos independentes
  • Maior controle sobre o export e import
  • Downtime é grande

Não esquece de validar se seu database está pronto para o Azure SQL Database através do Data Migration Assistant – Assessment

Para iniciar o seu processo de migração acesse o wizard através do SSMS.

Acesse Object Explorer –> Instance –> Database –> Botão direito –> Task –> Export Data-tier Application. Uma primeira janela de introdução será mostrada, avance para a próxima.

Nesse ponto você pode escolher entre salvar o .bacpac localmente ou no Azure Storage Account

  1.  Connect a sua storage account
  2. Indique o container onde o arquivo bacpac deverá ficar
  3. Nome do arquivo
  4. Um caminho local temporário deve ser indicado para que o processo tenha sucesso

Revise as informações, principalmente o espaço temporário disponível, e inicie a exportação do database. Através da janela de progresso podemos verificar o que o wizard está fazendo.

  1. Extrai o schema
  2. Valida o schema
  3. Exporta os dados (tabela por tabela)
  4. Upload do arquivo bacpac para o Azure Storage

Uma vez que o wizard terminou com sucesso não existe mais nada para fazer no SSMS e agora você tem o controle de quando e onde realizar o import. Acesse o Azure Portal e navegue até o seu servidor logico do SQL servers.

Acesse o item Overview e a opção Import database

 

 

  1. Indique sua subscription
  2. Local onde você fez o upload do arquivo bacpac

  1. Defina o service tier do database
  2. Escolha um nome para o database
  3. Collation que deseja utilizar
  4. Método de autenticação
  5. Login do administrador do servidor logico

 

 

 

 

Após revisar as informações e confirmar, o deploy deverá iniciar e uma notificação será apresentada no portal. Uma vez que sua requisição tenha sido completada seu database estará disponível para uso. Você pode verificar através do SSMS ou do Azure Portal.

O tempo total de deploy depende de alguns fatores como tamanho do seu database e service tier escolhido. Outra possibilidade é utilizar powershell para fazer o import do bacpac ao invés de usar o portal do Azure.

O código abaixo é um exemplo estático de como utilizar powershell.

#region connect to Azure
Login-AzureRmAccount
Get-AzureRmSubscription 
Select-AzureRmSubscription -SubscriptionName 'MSDN Platforms'

#list of commands 
Get-Command -Module AzureRM.Sql
#endregion

#region getting information and set variables

# Get the resource group name 
Get-AzureRmResourceGroup 
$resourcegroupname = "SQL-Database"

# Set an admin login and password for your server
$adminlogin = "admin"
$password = "yourpassword"

# Get server name - the logical server name has to be unique in the system
Get-AzureRmSqlServer -ResourceGroupName $resourcegroupname #| Select ServerName
$servername = "balabuchsqldb"

# The sample database name
$databasename = "AdventureWorks_Bacpac_PS"

# The storage account name and storage container name
Get-AzureRmStorageAccount -ResourceGroupName $resourcegroupname #| Select StorageAccountName
$storageaccountname = "sqldatabasemigration"

Get-AzureRmStorageAccount -ResourceGroupName $resourcegroupname | Get-AzureStorageContainer #| Select Name
$storagecontainername = "migration"

# BACPAC file name
Get-AzureRmStorageAccount -ResourceGroupName $resourcegroupname | Get-AzureStorageBlob -Container $storagecontainername #| Select Name
$bacpacfilename = "AdventureWorks.bacpac"

#endregion


#region importing bacpac

# Import bacpac to database with an S3 performance level
$importRequest = New-AzureRmSqlDatabaseImport -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -DatabaseName $databasename `
    -AdministratorLogin $adminlogin `
    -AdministratorLoginPassword  (ConvertTo-SecureString -String $password -AsPlainText -Force)`
    -DatabaseMaxSizeBytes "5000000" `
    -StorageKeyType "StorageAccessKey" `
    -StorageKey (Get-AzureRmStorageAccountKey -ResourceGroupName $resourcegroupname -StorageAccountName $storageaccountname).Value[0] `
    -StorageUri "https://$storageaccountname.blob.core.windows.net/$storagecontainername/$bacpacfilename" `
    -Edition "Standard" `
    -ServiceObjectiveName "S3"


# Check import status and wait for the import to complete
$importStatus = Get-AzureRmSqlDatabaseImportExportStatus -OperationStatusLink $importRequest.OperationStatusLink
[Console]::Write("Importing")
while ($importStatus.Status -eq "InProgress")
{
    $importStatus = Get-AzureRmSqlDatabaseImportExportStatus -OperationStatusLink $importRequest.OperationStatusLink
    [Console]::Write(".")
    Start-Sleep -s 10
}
[Console]::WriteLine("")
$importStatus

#endregion

#region scale down database

# Scale down to Basic after import is completed
Set-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -DatabaseName $databasename  `
    -Edition "Basic" `
    -RequestedServiceObjectiveName "Basic"

#endregion

Referências:

https://docs.microsoft.com/en-us/azure/sql-database/scripts/sql-database-import-from-bacpac-powershell

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-import

Categorias
Azure SQL Database How To Virtual PASS BR

Azure SQL Database – Migration tools – part 1

[bing_translator]

Escolher a ferramenta de migração nem sempre é uma tarefa fácil uma vez que devemos levar em conta todos os pré-requisitos estabelecidos pelo cliente. Por esse motivo temos que conhecer os principais métodos/ferramentas de migração e suas diferenças para fornecer uma melhor solução e é necessário uma preparação antes de iniciar sua migração. No post Azure SQL Database – Before you migrate você pode encontrar o que deve ser considerado para ter uma migração de sucesso.

A primeira ferramenta que podemos utilizar é o Data Migration Assistant e você pode verificar como utilizar essa ferramenta aqui!

Migration Wizard no SSMS

O SQL Server Management Studio (SSMS) é a ferramenta que pode ser usada através do Migration Wizard e é o método mais comum para migração de um database.

Por ser um método bastante comum, algumas características dessa ferramenta:

  • Suporta database a partir da versão SQL Server 2005
  • Excelente para database de tamanho pequeno e médio
  • .bacpac é criado apenas localmente
  • É um processo único – ou toda a migração é realizada com sucesso ou nada é feito
  • Manipula o export e import automaticamente
  • Downtime é grande

Não esquece de validar se seu database está pronto para o Azure SQL Database através do Data Migration Assistant – Assessment

Para iniciar o seu processo de migração acesse o wizard através do SSMS.

Acesse: Object Explorer –> Instance –> Databases –> Botão direito –> Task –> Deploy Database to Microsoft Azure SQL Database.

Uma primeira janela de introdução será mostrada, avance para a próxima.

  1. Conecte no seu servidor Azure SQL (link)
  2. Escolha um nome para o seu database, originalmente o wizard mantem o mesmo nome.
  3. Configurações do seu Azure SQL Database
    1. Escolha o nível de serviço (service tiers): Basic, Standard, Premium ou PremiumRS (no momento apenas essas estão disponíveis)
    2. Tamanho máximo do database depende de cada nível de serviço.
    3. Service Objective: Dentro de cada service tier temos diferentes níveis de performance e limite de storage, as DTU
  4. Local de armazenamento do arquivo .bacpac

 

Revise as informações, principalmente o espaço temporário disponível, e inicie a migração.

Através da janela de progresso podemos verificar o que o wizard está fazendo e posso citar alguns passos:

  1. Extrai o schema
  2. Valida o schema
  3. Exporta os dados (tabela por tabela)
  4. Cria o database no Azure
  5. Verifica e analisa o deploy do novo database
  6. Inicia o processo de importação do pacote (schema e dados)
  7. Desabilita os índices
  8. Importa os dados (tabela por tabela)
  9. Habilita os índices

Uma vez que o wizard tenha completado a tarefa seu database estará disponível para uso. Você pode verificar através do SSMS ou do Azure Portal.

Algumas configurações que eu sento falta no wizard que e que por sua vez utiliza a opção default:

  • Location
  • Resource Group
  • Subscription

Apenas a configuração da região não é possível alterar depois que o database é criado.
O tempo total de deploy depende de alguns fatores como tamanho do seu database e service tier escolhido.

Concluindo, esse é o metodo mais utilizado e mais facil porem é demorado. Recomendo que teste esse metodos assim como marque o tempo total gasto e verifique se é aceitavel para sua migração. Duvidas do que fazer antes de migrar seu database? Não deixe de ler o post Azure SQL Database – Before you migrate

Referencia:
https://docs.microsoft.com/en-us/azure/sql-database/sql-database-migrate-your-sql-server-database

Pluralsight – Azure SQL Database for the SQL Server DBA

Categorias
Azure SQL Database Virtual PASS BR

Azure SQL Database – Before you migrate

[bing_translator]

A migração para o Azure SQL Database exige um grande preparo e testes devem ser feitos para que se tenha êxito no resulto final. Esse preparo se deve ao fato de que o Azure SQL Database é um serviço na nuvem e existem limitações ou a forma que você está acostumado a utilizar um recurso muda.

Para se ter sucesso nessa migração devemos levar em conta alguns fatores:

  • Identificar os benefícios: Temos que identificar todos os benefícios e melhorias que iremos tirar proveito. Enumerar um por um e criar um roadmap para implementação de cada um deles é sempre uma boa estratégia. Nunca migre para a nuvem apenas para ser “fancy”.
  • Identificar bloqueios: O Data Migration Assistant ajuda nesse requisito. Identificar cada um deles e criar uma lista com prioridades de cada item auxiliará o processo de migração, porem existem bloqueios que impedem a migração como por exemplo SQL CLR que nesse momento ainda não é suportado.

 

  • Identificar o modelo de serviço: Se você pretende migrar um único database então Single Mode é perfeito para sua solução porem se pretende migrar mais de um database Elastic Pool deve ser avaliado.
  • Identificar o nível de serviço (service tier): Nesse ponto você irá verificar a capacidade de CPU/IO/Storage entre outros requisitos que seu database pode utilizar e lembre que quanto maior a capacidade maior será o valor pago pelo serviço.

 

 

  • Identificar Azure Region: Muitas pessoas esquecem de verificar qual a melhor região do Azure Datacenter para alocar seu database e principalmente qual a melhor região para alocar seu disaster recovey.
    Cada região tem serviços disponibilizados individualmente que outras regiões podem não contem e para saber melhor sobre o que cada região disponibiliza acesse o link.
  • Identificar a melhor ferramenta de migração: Existem algumas ferramentas que podemos utilizar para migrar um database e identificar qual é a melhor para o seu cenário pode ajudar a ter sucesso.

Algumas ferramentas de migração:

Obs.: Irei escrever sobre cada uma delas.

Cada uma delas tem suas particularidades e seus benefícios, entretanto a escolha da ferramenta é apenas mais uma etapa para ter sucesso na migração. Posso citar outros fatores como:

  • SLA – Garantir que o Service Level Agreement seja cumprido é um fato chave para o negócio e a escolha da ferramenta de migração vem de encontro com esse critério uma vez que podemos ter um downtime curto ou longo e cada uma das ferramentas proporciona um tempo necessário para completar a migração.
  • Aplicação – Garantir que sua aplicação não tem incompatibilidades, erros ou problemas com o Azure SQL Database é fundamental e isso é um fator que não podemos controlar pois dependemos dos desenvolvedores ou fornecedores.
  • Performance – Os usuários finais sempre esperam que a aplicação continue com a performance atual ou que tenham uma experiencia melhor na performance depois da migração. Nesse critério o nível de serviço escolhido é um grande potenciador ou impedidor de performance. Outro fator que deve ser revisto são as queries que consomem mais recursos e começar um trabalho otimizar seu código.
  • Documentação – Documentar cada etapa da migração é fundamental para o sucesso pois dessa forma você terá controle do que está acontecendo e principalmente estime o tempo gasto em cada etapa.
  • Testes – Antes de migrar seu database para o ambiente de produção realize testes de migração para um ambiente de teste onde você é capaz de documentar cada etapa, marcar o tempo gasto em cada etapa e verificar se a aplicação está funcionando com a performance aceitável e sem erros. Repita esse passo quantas vezes achar necessário para não ter surpresas no momento da migração para produção.

Para concluir eu acredito que o preparo é a chave fundamental para obter sucesso na migração para o Azure SQL Database. Estude, crie laboratórios, faça testes, simule erros para todas as alternativas e principalmente esteja confiante  em você mesmo!

Referencia:

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-migrate-your-sql-server-database

Pluralsight – Azure SQL Database for the SQL Server DBA

Categorias
Azure SQL Database How To SQL Server Virtual PASS BR

Data Migration Assistant – Migration

[bing_translator]

A ferramenta DMA v3.3 nesse momento tem duas opções de projetos: Assessment e Migration.
No post anterior Data Migration Assistant – Assessment falei um pouco sobre a funcionalidade de Assessment para assessorar e minimizar o impacto da migração de databases. Esse é o primeiro passo que você deve tomar para realizar uma migração e após verificar todos os itens dos relatórios você está “pronto” para iniciar a migração, pelo menos por parte do database não esqueça de verificar se a aplicação está preparada para a migração.

Ao iniciar a ferramenta DMA crie um projeto do tipo Migration onde iremos definir qual tipo de servidor de origem e destino.

Nesse momento temos que indicar qual o escopo da migração, que pode ser:

  • Schema and data
  • Schema only
  • Data only

A partir dessas opções podemos criar vários cenários para migração de um database como por exemplo:

  • Criar um servidor de teste e um database apenas com os metadados (schema); realizar o apontamento da aplicação para esse servidor fazendo assim um teste também com a aplicação.
  • Se precisar de poucos dados, aquelas famosas tabelas de configurações, você pode importar apenas o que precisa.

Desse ponto de vista temos uma flexibilidade enorme para trabalhar e eu escolhi o escopo: Schema and data para demonstrar do início ao fim o processo.

De forma simples o wizard irá te ajudar e nesse processo teremos 6 etapas sendo a primeira escolher a instancia e database de origem.

Uma tarefa que o wizard não faz é criar o database no Azure e por isso você deve criar um database vazio através do portal, powershell ou CLI antes de continuar. Basta seguir os passos desse link.

Eu criei um database chamado AdventureWorksDMA através do portal e o próximo passo é escolher quais objetos serão migrados.

Uma vez que tenha escolhido os objetos que serão migrados o passo a seguir é gerar os scripts desses objetos.

Aqui você tem a opção de salvar o script para analisar posteriormente, copiar para qualquer editor de texto ou realizar o deploy diretamente através do DMA que irá fazer o deploy para o Azure SQL Database.

Uma janela com informações dos resultados irá mostrar o progresso do deploy e os comandos executados. Ao finalizar existe a opção de redeploy ou iniciar a migração dos dados e como nosso objetivo é ter uma migração completa vamos seguir com a migração dos dados.

Selecione as tabelas desejadas ou todas e inicie o seu processo de migração.

O tempo que a migração depende de alguns fatores dentre eles posso citar: quantidade de tabelas e registros em cada uma delas e a performance do seu Azure SQL Database (DTU), no meu caso utilizei S0 (10 DTU).

Uma vez que a migração dos dados terminou com sucesso você pode se conectar no Azure SQL database através do SSMS (Azure SQL Database – SQL Authentication) para verificar que sua migração está finalizada com sucesso.

Categorias
Azure SQL Database How To SQL Server Virtual PASS BR

Data Migration Assistant – Assessment

[bing_translator]

Migração de um database é uma rotina comum na vida de um DBA e essa atividade pode ser para uma versão mais atual do SQL Server ou para o Azure SQL Database. A Microsoft sempre tentou auxiliar essas migrações com ferramentas como por exemplo o Upgrade Advisor. Por muito tempo utilizei essa ferramenta para as migrações que realizei pois ela gerava um relatório com todos os possíveis “problemas” que poderia ter.

Recentemente precisei migrar um database on-premise para cloud e ao verificar a versão mais atual do Upgrade Advisor descobri que a Microsoft decidiu descontinuar essa ferramenta. Você ainda pode baixar a ferramenta atrás desse link porem eu aconselho a utilizar a nova ferramenta o Data Migration Assistant (DMA). Essa ferramenta trouxe novas capacidades e facilidades onde uma delas é centralizar na mesma ferramenta as opções de realizar a migração ou apenas realizar a validação do database para uma futura migração.

É sobre essa nova ferramenta DMA que irei falar um pouco hoje.

Após fazer o download através do link acima e instalar a ferramenta, você pode notar na tela iniciar uma facilidade que é a criação de projetos. Estou utilizando a versao 3.3

Nesse momento existem dois tipos de projetos:

  • Assessment
  • Migration

O Assessment é a funcionalidade que iremos utilizar para verificar os possíveis problemas e incompatibilidades que temos ao migrar um database.

Depois de dar um nome ao seu projeto você deve escolher o tipo de servidor de origem que no meu caso só tenho a opção de SQL Server.

Nesse momento você deve selecionar qual o seu objetivo final, ou seja, qual o tipo de servidor que o seu database será hospedado. No meu caso 3 opções são apresentadas: Azure SQL Database, SQL Server e SQL Server on Azure Virtual Machines.

Como tenho trabalho com Azure SQL Databases vou utilizar essa opção para demonstração.

Agora que você escolheu as opções e criou o projeto uma nova janela irá apresentar quais os tipos de relatórios você gostaria de gerar.

Nesse momento é possível optar por gerar relatórios separados, o que pode ser útil quando existe uma lista grande de itens que estão sendo tratados aos poucos e você pode medir quanto esforço foi realizado ou falta a ser feito.

  • Check database compatilibity – verificará problemas que podem ser bloqueadores para a migração assim como features descontinuadas.
  • Check feature parity – verificará por features que não são suportadas ou são parcialmente suportadas.

Um terceiro tipo de relatório está por vim e parece ser bem interessante uma vez que ele informará quais são as possíveis features que podem ser utilizadas no seu database uma vez que você realizar a migração e isso é um benefício que pode ser traduzido em performance, tamanho, segurança entre outros (essa é a minha opinião sobre o que esperar desse relatório)

Próximo passo é escolher a instancia SQL Server e o(s) database(s) que fará parte do projeto de migração.

 

Uma lista com os databases selecionados será apresentada e você pode adicionar ou remover servidores de origem dentro do seu projeto, ou seja, pense que uma aplicação tem mais de um database em mais de uma instancia e com isso é possível criar um projeto com múltiplas instancias SQL Server e múltiplos databases.

Após iniciar o Assessment e a ferramenta terminar de analisar, você terá seus relatórios prontos e sua análise desses é extremamente fácil uma vez que está divido em seções.

Relatório: SQL Server features parity

  1. Recomendações e informações sobre features
  2. Detalhes sobre uma das recomendações selecionadas.
  3. Nível de aplicabilidade da recomendação. (Não se aplica a todas as recomendações)

Relatório: Compatility issues

  1. Issue (problema) agrupado por categorias
  2. Detalhes sobre o issue
  3. Objetos dentro database que são impactados pelo issue.

Dessa forma fica fácil visualizar o que devemos fazer para corrigir cada um dos issues antes de migrar o database.

No campo superior direito existem duas opções: Restart Assessment e Delete Assessment. Uma forma rápida para regerar o relatório ou excluir!

Para concluir é possível exportar o relatório para dois formatos: CSV e JSON. Particularmente o formato CSV não me agradou e o JSON é a nova onda do momento de transferia de dados de forma leve!

Categorias
Virtual PASS BR

Definindo o SQL Azure

Devemos começar a definir o SQL Azure, que é uma escala maciça de serviços de banco de dados relacional que é construído usando hardware comodato. Ele fornece um ambiente compartilhado com opções de alta disponibilidade e é um ótimo lugar para executar aplicações web e departamentaisSQL Azure lhe dá a dimensão e funcionalidade de uma oferta de banco de dados de nível empresarial sem ter que lidar com a tecnologia de questões envolvidas. SQL Azure é construído sobre a plataforma Windows Server e SQL Server e oferece failover automatizado para otimizar a disponibilidade de seus aplicativos. Você pode escalar as suas aplicações com facilidade e com o particionamento eficaz das bases de dados você tem escala virtualmente ilimitada.Em vez de precisar aprender uma nova maneira de desenvolver o código para aplicações de banco de dados, o SQL Azure utiliza o familiar T-SQL que já está em uso com SQL Server e usa o protocolo de rede padrão TDS para a comunicação com o SQL Server. SQL Azure vai parecer muito familiar aos desenvolvedores e administradores que estão acostumados a trabalhar com bancos de dados relacionais.Os clientes de bancos de dados são capazes de rapidamente disponibilizar e aumentar a capacidade de demanda. Alta disponibilidade e tolerância a falhas são automáticas e o cliente não precisa lidar com problemas de manutenção do banco de dados porque são totalmente automatizadas.Finalmente, um modelo simples e flexível de preços significa que os clientes pagam pela utilização que eles precisam e mais importante, pode pagar à medida que crescem.Ao definir o SQL Azure é, devemos considerar também que SQL Azure não é apenas uma cópia padrão de SQL Server hospedado na nuvem. Banco de dados SQL Azure fornece hospedagem não SQL Server hospedagem. A noção de um “servidor” existe, mas é um conceito lógico. O servidor não é algo que você pode ou necessita gerir. Com padrão hospedado sistemas Windows Server e SQL Server Management ainda é tipicamente de responsabilidade do cliente. Com o SQL Azure não é esse o caso, como a gestão do serviço é totalmente automatizada e os recursos são geridos de uma forma que maximiza a disponibilidade do serviço para o usuário. Por exemplo, se outros usuários começam a utilizar muito o serviço, é inteiramente possível que o SQL Azure quadro de gestão poderia movê-lo para um servidor diferente sem a sua aplicação, mesmo percebendo, para garantir seu desempenho

Categorias
Virtual PASS BR

SQL Server na nuvem

Disponibilizar dados de uma forma rápida e eficiente é uma das principais razões que as pessoas desejam utilizar os serviços via Internet. O SQL Azure fornece serviços do estilo do SQL Server como parte da plataforma Windows Azure. As ofertas iniciais são serviços de banco de dados principal e sincronização de dados. O objetivo é fornecer serviços adicionais como Reporting Analytics.

SQL Azure suporta a maioria dos objetos comuns do SQL Server, como tabelas, índices, views, stored procedure, triggers e muitos mais. O foco principal do SQL Azure é sobre os dados não sobre a execução física subjacente de como os dados são armazenados. Isso reduz a sobrecarga de gerenciamento e à necessidade de planejamento de capacidade de execução, e também a gestão de arquivos de log, etc.

Está tudo configurado através de um simples Web Portal e o objetivo é para a gestão totalmente automatizada. Atualizações para o SQL Server são automaticamente gerenciados e adicionar novos recursos e atualizações podem ocorrer sem interrupção aos sistemas do cliente. Novos bancos de dados podem ser provisionados quase instantaneamente e você só paga o que você precisa para usar.

clip_image002

 

Existem várias maneiras de fazer uso de SQL Azure:

  • Aplicações do Windows Azure pode armazenar dados em SQL Azure, mas aplicações locais também pode utilizar um banco de dados SQL Azure.
  • Você pode ter uma sincronização de dados web com base instituída para as empresas e o seu parceiro.
  • Bases de dados SQL Azure pode ser usada como um hub no meio de um framework de sincronização, como o SQL Azure Data Sync.
  • Para mais rica análise de dados, podemos combinar SQL Azure com processamento local nas aplicações como o Reporting Services.

SQL Azure também fornece um nível automático de alta disponibilidade para seus dados. Você não precisa para planejar e implementar a replicação dos dados entre os servidores. SQL Azure automaticamente mantem três cópias de seus dados.

Para evitar latência considerável nas conexões à Internet, os Windows Azure Data Centers estão localizados em vários lugares ao redor do mundo. Isso faz com que SQL Azure seja ideal para web e aplicações departamentais, mas, além disso, pode ajudar os fornecedores de software que desejam oferecer SaaS (Software as a Service).

Existem várias maneiras para se conectar ao SQL Azure. Os aplicativos podem usar o protocolo padrão TDS (Tabular Data Stream) protegido por SSL (Secure Sockets Layer) para fazer ligações diretas para o SQL Azure. Como alternativa os clientes baseado na Web pode usar uma conexão HTTP (Hypertext Transfer) ou HTTPS (Hypertext Transfer Secure) para conectar aplicativos ou camadas de serviço executado dentro do Windows Azure, essas camadas de serviço podem então se conectar ao SQL Azure.

[]’s

Categorias
Virtual PASS BR

Beneficios do SQL Azure

Os benefícios de usar SQL Azure são múltiplos. Estes incluem o gerenciamento, alta disponibilidade, escalabilidade, um modelo de desenvolvimento familiar, e um modelo de dados relacional.

Gerenciamento Automático

SQL Azure fornece a escalabilidade e a funcionalidade de uma empresa de data center, sem despesas administrativas que são associados com as instâncias do SQL Server. Esta capacidade deGerenciamento Automáticopermite às organizações fornecer serviço de dados para aplicações, sem aumentar a carga de apoio do departamento de TI ou distraindo os funcionários conhecedores de tecnologia de suas funções essenciais, a fim de manter um aplicativo de banco de dados do departamento.

Com o SQL Azure, você pode provisionar o armazenamento de dados em minutos. Isso reduz os custos iniciais de serviços, permitindo-lhe disposição apenas o que você precisa. Quando suas necessidades mudam, você pode facilmente estender seus dados para atender a essas necessidades.

Alta Disponibilidade

SQL Azure é construído sobre as tecnologias Windows Server e SQL Server, e é suficientemente flexível para lidar com as variações no uso e de carga. O serviço replica múltiplas cópias dos dados para múltiplos servidores físicos para manter a disponibilidade de dados e continuidade de negócios. No caso de uma falha de hardware, SQL Azure fornece failover automático para otimizar a disponibilidade de sua aplicação.

Escalabilidade

Uma das principais vantagens do SQL Azure é a facilidade com que você pode escalar a sua solução. O modelo “pay-as-you-grow” de preços oferece vantagens, pois você só paga o armazenamento que você usa, de modo que você pode reduzir o serviço quando não precisar mais dele.

Modelo de Desenvolvimento Familiar

Quando os desenvolvedores criam aplicativos que usam SQL Server, eles usam bibliotecas de clientes que utilizam o tabular data stream (TDS), que é um protocolo de comunicação entre o cliente e o servidor. SQL Azure fornece a mesma interface TDS, para que você possa usar as mesmas ferramentas e bibliotecas para construir aplicativos que são armazenados no SQL Azure.

Modelo de Dados Relacional

SQL Azure vai parecer muito familiar aos desenvolvedores e administradores, pois os dados são armazenados no SQL Azure como ele é armazenado no SQL Server, usando Transact-SQL.
Dentro de cada servidor SQL Azure, você pode criar várias bases de dados que tem tabelas, views, stored procedures, índices e outros objetos de banco de dados. Este modelo de dados faz bom uso de seu projeto de banco de dados relacionais existentes e habilidades de programação Transact-SQL, e simplifica o processo de migração de aplicações de banco de dados existente localmente para o SQL Azure.

[]’s….