André Rodrigues (SQL MAGU) https://docs.microsoft.com/archive/blogs/andrecr/feed.xml Um blog para falar sobre SQL Server Wed, 17 Apr 2019 03:37:27 GMT pt_BR hourly 1 Migrando dados On-Premises para o Azure com o novo Azure Database Migration Service https://docs.microsoft.com/archive/blogs/andrecr/migrando-dados-on-premises-para-o-azure-com-o-novo-azure-database-migration-service Fri, 16 Feb 2018 16:51:34 GMT https://blogs.msdn.microsoft.com/andrecr/?p=35   Recentemente a Microsoft anunciou o Public Preview do Azure Database Migration Service (Azure DMS), uma nova forma de levar seus dados em bases SQL Server ou de outras fontes de dados para o Azure: https://blogs.msdn.microsoft.com/datamigration/2017/11/15/announcing-the-azure-database-migration-service-public-preview/ Pensando nisso, resolvi montar este tutorial mostrando como migrar uma base de dados SQL Server localizada em um ambiente On-Premises para o Azure SQL Database usando o Azure DMS. O tutorial explica desde de como criar uma conexão entre o Azure e um servidor em Hyper-V (On-Premises) usando VPN Site-to-Site até a migração dos dados com o Azure Database Migration Service.   Pré-Requisitos     HYPER-V   Abra o Virtual Switch Manager do Hyper-V e crie dois novos switches virtuais conforme abaixo: Nome: External – Tipo: External (Associe a interface que provê sua conexão com a Internet) Nome: Private – Tipo: Private Crie uma máquina virtual nova com um disco dinâmico de 128 GB e 2 adaptadores de rede onde um deles deverá ser associado ao virtual switch External e o outro ao Private que criamos nos passos anteriores: Instale o Windows Server 2016 + SQL Server 2016 ou superior e restaure o backup da base AdventureWorks2016 no SQL Server que você acabou de instalar. Agora, você irá notar na VM que um dos adaptadores de rede vai estar com conexão na Internet, nomeie ele na VM como External para evitar confusão. O outro adaptador nomeie como Private: No adaptador External, clique com o direito, e mantenha apenas as opções de TCP/IP marcadas conforme abaixo: Deixe as configurações de IP e DNS em automático: Clique em “Advanced...” e na aba WINS marque a opção Disable NetBIOS over TCP/IP: No adaptador Private configure um IPv4 com máscara e DNS, não precisa de Gateway, no caso usarei: Subnet Mask = 255.255.255.0 DNS = 192.168.0.1 IPv4 = 192.168.0.2 Por enquanto, está é nossa configuração para o Hyper-V, agora vamos partir para o Azure.   AZURE   Resource Group   Abra o Azure Portal, a primeira coisa que devemos fazer é criar um novo grupo de recursos, vou chama-lo de SAMPLE-DMS-S2S-RG: Virtual Network   Dentro do grupo de recursos que foi criado, adicione uma Virtual Network, vou chama-la de SAMPLE-DMS-S2S-Vnet: Em address space adicione 10.2.0.0/16. Em subnet name vou dar o nome de SAMPLE-DMS-S2S-Vnet-Subnet. Em subnet address range adicione 10.2.0.0/24. Em resource group, selecione nosso grupo de recursos, no meu caso SAMPLE-DMS-S2S-RG: Virtual Network Gateway   Agora, vamos criar um novo Virtual Network Gateway dentro do nosso Resource Group, ele irá conter nossa segunda subnet. Vá em Virtual Networks> SAMPLE-DMS-S2S-Vnet > Subnets: Clique em + Gateway Subnet e em address range use 10.2.1.0/24: Você deve ver agora as duas Subnets conforme a imagem abaixo: Agora dentro do nosso RG, adicione o Virtual Network Gateway e clique em Create: Vou chamar o Virtual Network Gateway de SAMPLE-DMS-S2S-VnetGW. Deixe o gateway type como VPN e seu vpn type como Route-based. O SKU deixe em Basic. Para a Virtual Network selecione a que criamos, no meu caso SAMPLE-DMS-S2S-Vnet. Em Public IP, como não temos um, teremos que criar, vou chama-lo de SAMPLE-DMS-S2S-VnetGW-PublicIP. Lembrando que pode demorar um pouco até que um IP seja provisionado. Clique em Create ao final: Obs.: Esta etapa pode levar vários minutos.   Local Network Gateway   Agora que criamos o Virtual Network Gateway, vamos criar um Local Network Gateway. Em nosso grupo de recursos, adicione o Local Network Gateway e clique em Create: Vou chamá-lo de SAMPLE-DMS-S2S-LocalNetGW. Em IP address, precisamos voltar lá na nossa VM no Hyper-V e descobrir qual seu IP público, para isso, dentro da VM abra o prompt de comando e rode o seguinte: nslookup myip.opendns.com resolver1.opendns.com No meu caso meu IP público é 177.113.183.174: Em Address space, adicione a sub-rede do network adapter Private da nossa VM no Hyper V, no caso 192.168.0.2/32, ao término clique em Create: New connection - Local Network Gateway   Agora, precisamos criar uma conexão no nosso Local Network Gateway. Para isso, vá em suas settings>connections e clique em +Add: Vou chama-la de SAMPLE-DMS-S2S-LocalNetGW-Conn. Defina seu Virtual Network Gateway com o que criamos anteriormente, no meu caso, SAMPLE-DMS-S2S-VnetGW. Defina uma Shared Key (PSK) e lembre-se de anota-la pois iremos precisar dela depois em nossa VM no Hyper-V, ao final clique em OK: Se todas etapas foram devidamente feitas até aqui podemos partir para a configuração do RRAS em nossa VM no Hyper-V.   Configuração do RRAS na VM do Hyper-V.   Em nossa VM no Hyper abra o Server Manager. Vá em Manage>Add Roles and Features. Em Before You Begin clique em Next. Em Selection installation type selecione Role-Based or Feature-based installation e clique em Next. Em Select server destination clique em Next. Em Select server roles selecione Remote Access e clique em Next. Em Select features clique em Next. Em Remote Access clique em Next. Em Role Services marque Direct Access and VPN (RAS): Clique em Add Features: Depois marque Routing também e clique em Next: Em Web Server Role (IIS) clique em Next. Em Select role services deixe o default e clique em Next. Em Confirmation clique em Install. Após o término da instalação, no Server Manager, em Tools, clique em Routing and Remote Access: Clique com o direito no nome do computador e selecione Configure and Enable Routing and Remote Access: Na primeira tela clique em Next. Em Configuration, marque Secure connection between two private networks e clique em Next: Em Demand-Dial Connections marque Yes e clique em Next: Em IP Address Assignment selecione Automatically e clique em Next: Clique em Finish e aguarde: Após isso, uma nova janela já vai abrir para configurarmos a Demand-Dial Interface, clique em Next: De um nome e clique em Next, no caso vou chama-la de SAMPLE-S2S-RRAS-Azure: Em Connection Type selecione Connecting using virtual private network (VPN) e clique em Next: Em VPN type selecione IKEv2 e clique em Next: Em IP Address, vá em nosso Virtual Network Gateway no Azure e copie seu Public IP (Lembra que o criamos?), cole o endereço copiado e clique em Next: Em Protocols and Security selecione Route IP Packets on this interface e clique em Next: Em Static Routes, vamos adicionar a rota da nossa subnet no Azure, no caso 10.2.0.0, 255.255.255.0, Metric: 24, depois clique em Next: Depois cheque a rota adicionada em Static Routes: Em Dial-Out Credentials de um nome qualquer e clique em Next e na última tela em Finish: Agora em Routing and Remote Access > Network Interfaces, clique com o direito na interface que criamos, no meu caso, SAMPLE-S2S-RRAS-Azure, depois clique em Propriedades: Na aba Security, marque a opção Use preshared key for authentication e informe a mesma PSK que usamos no Azure: Na aba options, marque a opção Persistent Connection: Testando a conexão entre o ambiente On-Premisses e o Azure   Agora, clique com o direito na interface, no meu caso SAMPLE-S2S-RRAS-Azure e clique em Connect. Se deu tudo certo, a conexão será estabelecida e você poderá comprovar isso olhando a coluna Connection State e lá no Azure, a coluna STATUS dentro da Connection do Local Network Gateway: Se por acaso a conexão não puder ser estabelecida, verifique se as portas do Azure estão liberadas no Firewall e também não se esqueça dos dispositivos de rede, os links a seguir podem ajudar: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/vpn https://blogs.technet.microsoft.com/rrasblog/2006/06/14/which-ports-to-unblock-for-vpn-traffic-to-pass-through/ Faça um ping da VM do Hyper-V no IP 10.2.0.0, o mesmo deve responder com sucesso: Data Migration Assistant – Migração do schema do banco On-Premisses para o Azure   Agora vamos realizar a migração do Schema do banco através do Data Migration Assistant (DMA). Se voce ainda não baixou o DMA, baixe e o instale em nossa VM no Hyper-V, (Download: https://www.microsoft.com/en-us/download/details.aspx?id=53595) Abra o DMA, na esquerda, clique no sinal de “+”, selecione Migration, de um nome ao projeto, no meu caso SAMPLE-AzureDMS-Demo, em Source deixe como SQL Server e target como Azure SQL Database, em migration scope deixe selecionado Schema Only e clique em Create: Em connect to source informe o nome da instância On-Premises, defina o método de autenticação que preferir, no meu caso irei usar Windows Authentication, marque as opções de Encrypt Connection e Trust Server Certificate e clique em Connect: Selecione a base AdventureWorks2016 que havíamos restaurado inicialmente e clique em Next: Em Connect to target server, clique em Create New Azure SQL Database: Abra o portal do Azure e crie em nosso Resource Group uma nova Azure SQL Database em branco chamada AdventureWorks2016: Em Server, crie um novo, no meu caso vou chama-lo de azuredmstestserver: Na SQL database que acabamos de criar clique em Set server firewall: Crie uma regra contendo o IP público da nossa VM no Hyper-V, no meu caso 177.113.183.174, clique em Save: Volte ao DMA e informe o server name da SQL database criada, método de autenticação, marque as opções de Encrypt connection e Trust Server Certificate e clique em Connect: Selecione a Azure SQL Database que criamos e clique em Next: Em Select objects, deixe todos objetos marcados e clique em Generate SQL Script: Após o script ter sido gerado clique em Deploy schema: Aguarde a execução do deploy: Após o deploy do schema feche o DMA.   Azure Database Migration Service – Data migration   Agora que nosso schema já foi migrado para o Azure, vamos levar os dados usando o novo serviço Azure Database Migration Service. No menu do Portal clique em Subscriptions: Após selecionar a assinatura, vá em Resource Providers: Procure por Microsoft.DataMigration e clique em Register. Agora clique em Create a resource, localize o Azure Database Migration Service e clique em Create: Nas configurações do Azure DMS, de um nome ao recurso (chamei o meu de SAMPLE-AzureDMS-Demo), selecione a Vnet que criamos, no meu caso SAMPLE-DMS-S2S-Vnet e clique em Create: Depois que o deploy finalizar, abra o recurso e clique em + New Migration Project: De um nome ao projeto, no meu caso AzureDMSDataMigration e clique em Create: Agora, em Select source, coloque o IP do adaptador Private da nossa VM no Hyper-V (que é também o IP que responde nosso SQL Server), informe o usuário (no meu caso o sysadmin) e clique em Save: Na próxima etapa vamos selecionar a base AdventureWorks2016 e clicar em Save: Agora vamos informar os dados do nosso SQL database de destino e clicar em Save: A próxima tela é um sumário do que está envolvido no nosso projeto dentro do DMS, confira as informações e clique em Save: Agora, estaremos de volta a tela do nosso DMS, clique em cima do projeto que acabamos de criar e em cima clique em + New Activity e depois em Run Database Migration: Será necessário redigitar a senha do source server e target server, faça isso e clique em Save. Na etapa Map to target database note que a SQL database que já havíamos criado anteriormente será selecionada automaticamente, aqui também devemos marcar a opção SET SOURCE DATABASE READ-ONLY, feito isso clique em Save: Na etapa Select tables, como já levamos o schema das tabelas da base On-Premisses anteriormente, ele automaticamente já fez o link delas com as tabelas vazias da Azure SQL database, clique em Save: Agora, temos uma tela sumarizando o que foi selecionado, de um nome para a atividade (no meu caso AzureDMSActivity), em Validation Option deixe como Do Not Validade afinal é somente um teste, confirme as demais informações e estando tudo certo clique em Run migration: Agora nossa atividade no DMS estará com status de Running: Clicando na atividade é possível acompanhar a migração ou mesmo para-la: Aguarde o DMS terminar a migração dos dados entre as tabelas, no meu caso levou ~4 minutos: Voce também pode fazer download de um PDF contendo detalhes da migração, basta clicar em Download report: Exemplo de relatório: Clicando na linha indicativa da base de dados você também consegue ver o status por tabela pelo próprio portal: Bom pessoal era isso, espero que o tutorial tenha sido útil a vocês!   Abraço e até a próxima!   Referências:   Migrate SQL Server to Azure SQL Database https://docs.microsoft.com/en-us/azure/dms/tutorial-sql-server-to-azure-sql Differentiating Microsoft’s Database Migration Tools and Services https://blogs.msdn.microsoft.com/datamigration/2017/10/13/differentiating-microsofts-database-migration-tools-and-services/ Let’s Configure Azure Site-to-Site VPN with RRAS in Azure Resource Manager! https://blogs.technet.microsoft.com/jletsch/2016/03/15/lets-configure-azure-site-to-site-vpn-with-rras-in-azure-resource-manager/]]> Entendendo os PAGE SPLITs e o que seria o FILL FACTOR. https://docs.microsoft.com/archive/blogs/andrecr/entendendo-os-page-splits-e-o-que-seria-o-fill-factor Tue, 21 Nov 2017 22:21:40 GMT https://blogs.msdn.microsoft.com/andrecr/?p=26 https://sqlmagu.blogspot.com.br/) mas vou tentar voltar as poucos (devagar rsrs) e agora vou postar as coisas novas por aqui. Como DBA SQL Server você provavelmente já sabe que o SQL Server aloca páginas de dados e índices de 8 KB e talvez, indo mais fundo no assunto, provavelmente já tenha ouvido falar sobre a operação PAGE SPLIT e o termo FILL FACTOR certo? Bom, no artigo de hoje vou explicar cada um deles e sugerir algumas coisas que podem ser úteis na administração da sua instância com SQL Server. O que seria um PAGE SPLIT? Quando o SQL Server vai fazer uma alocação em uma página de dados proveniente de um INSERT ou de um UPDATE em um índice CLUSTERED ou NON-CLUSTERED (nível folha e intermediário) e não existe mais espaço na página para manipular a linha afetada, ele realiza o que chamamos de PAGE SPLIT, ou seja, cria uma nova página de dados e movimenta mais ou menos a metade das linhas para ela. Em uma tabela sem índices (HEAP) não existem PAGE SPLITS, pois não existe uma ordenação logica dos dados, as alocações são baseadas nos FORWARDED RECORDS. Certo, mas onde entra o FILL FACTOR nesta história toda? Nas páginas de um índice CLUSTERED ou NON CLUSTERED, o FILL FACTOR de um índice define o quanto da página de dados será preenchido, onde ele é considerado nas seguintes situações:
  • Na criação do índice ou em seu REBUILD.
  • No nível folha e nos níveis intermediários quando o PAD_INDEX é especificado para o índice. Onde o PAD_INDEX é sempre igual ao FILL FACTOR.
Se você tem em determinado índice um FILL FACTOR em 70% por exemplo, significa que 30% do tamanho total da página será deixado sem preenchimento, este espaço vazio fica entre as linhas do índice e não no final dele. O bom PAGE SPLIT e o PAGE SPLIT ruim Bom, agora que você já tem uma noção do que é PAGE SPLIT e do que é FILL FACTOR, podemos falar sobre a diferença entre um bom PAGE SPLIT e um PAGE SPLIT ruim. O bom PAGE SPLIT é aquele que ocorre sempre ao final do índice, imagine uma inserção em um campo IDENTITY, onde os dados são sempre inseridos em ordem ao final do índice, quando não existe mais espaço na última página, uma nova página vazia será alocada e os dados continuarão sendo inseridos. Agora pense por exemplo em uma inserção no meio do índice, ou mesmo em um UPDATE que cresce a linha de modo que ela deixe de caber na página, o SQL Server precisa, portanto, alocar uma nova página e movimentar parte dos dados da página original para ela, isso acaba gerando mais IO, fragmentação e aumento do transaction log, este seria o PAGE SPLIT ruim. Certo...o que eu consigo fazer para nunca mais ter PAGE SPLITS ruins? A reposta é: nada, massss você pode tentar algumas coisas para pelo menos diminuir a ocorrência deles! Como? Lembra do FILL FACTOR? Ajustando o FILL FACTOR Não existe uma formula mágica de calcular qual é o FILL FACTOR ideal para cada índice que você possui, o melhor a fazer é acompanhar a carga de trabalho, identificar os índices com maior ocorrência de PAGE SPLITS e ir ajustando aos poucos o seu valor. De que forma você pode fazer isso? Se você está em um SQL Server anterior ao 2012, você pode começar olhando as colunas leaf_allocation_count e nonleaf_allocation_count da DMV sys.dm_db_index_operational_stats, dê uma olhada na query mencionada no site abaixo: https://social.technet.microsoft.com/wiki/contents/articles/25473.sql-server-dmv-to-track-page-split.aspx Com ela você pode ter uma ideia dos PAGE SPLITS considerando que ela captura a informação somente se o metadados dos objetos estiverem em cache, caso o serviço do SQL Server seja reiniciado ou a base alvo passe por um detach/attach por exemplo, a DMV não irá retornar à informação esperada, outro ponto aqui é entender que todas operações de PAGE SPLITS serão consideradas, sejam eles bons ou ruins. Existe uma outra forma de saber como estão os PAGE SPLITS dos índices ao longo do tempo usando EXTENDED EVENTS e a vantagem se comparado a DMV anterior é que podemos filtrar a informação somente nos PAGE SPLITS ruins, basicamente precisamos criar uma sessão de xevents com o evento sql_server.transaction_log e filtrar o campo operation com o valor = 11, que significa LOP_DELETE_SPLIT. Esta operação indica que o SQL Server está movendo dados de uma página a outra, ou seja, PAGE SPLITS ruins. Existe um artigo excelente do Kehayias que te ajuda a montar esta sessão de eventos estendidos: https://www.sqlskills.com/blogs/jonathan/tracking-problematic-pages-splits-in-sql-server-2012-extended-events-no-really-this-time/ A query abaixo é uma adaptação do código do Kehayias para que a informação possa ser lida do arquivo ao invés do histograma: SELECT  o.name AS table_name, i.name AS index_name, SplitCount, i.fill_factor FROM ( SELECT DB_NAME(TAB.database_id) AS DatabaseName, COUNT(TAB.[alloc_unit_id]) AS SplitCount, alloc_unit_id FROM( SELECT DATEADD(mi, DATEDIFF(mi, GETUTCDATE(), CURRENT_TIMESTAMP), xevents.event_data.value('(event/@timestamp)[1]', 'datetime2')) AS [event time] , xevents.event_data.value('(event/data[@name="database_id"]/value)[1]', 'int') AS [database_id], xevents.event_data.value('(event/data[@name="database_name"]/value)[1]', 'varchar(max)') AS [database name], xevents.event_data.value('(event/data[@name="alloc_unit_id"]/value)[1]', 'BIGINT') AS [alloc_unit_id] FROM sys.fn_xe_file_target_read_file ('C:\temp\PageSplitTracking*.xel', -- ALTERE AQUI COM AS INFORMAÇÕES DO SEU ARQUIVO 'C:\temp\PageSplitTracking*.xem', -- ALTERE AQUI COM AS INFORMAÇÕES DO SEU ARQUIVO NULL, NULL) CROSS APPLY (SELECT CAST(event_data AS XML) AS event_data) AS xevents ) TAB GROUP BY TAB.alloc_unit_id, TAB.database_id ) AS tab JOIN sys.allocation_units AS au ON TAB.alloc_unit_id = au.allocation_unit_id JOIN sys.partitions AS p ON au.container_id = p.partition_id JOIN sys.indexes AS i ON p.OBJECT_ID = i.OBJECT_ID AND p.index_id = i.index_id JOIN sys.objects AS o ON p.OBJECT_ID = o.OBJECT_ID Pessoal, espero que este artigo seja útil para vocês no dia a dia quando o assunto for diminuir a ocorrência de PAGE SPLITS ruins, qualquer dúvida estou à disposição! Um abraço! André Rodrigues   Referências: https://sqlblog.com/blogs/kalen_delaney/archive/2009/11/11/fragmentation-and-forwarded-records-in-a-heap.aspx  https://blogs.msdn.microsoft.com/craigfr/2009/07/29/correction-to-my-prior-post-on-sys-dm_db_index_operational_stats/ https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-index-operational-stats-transact-sql https://technet.microsoft.com/en-us/library/bb630339(v=sql.110).aspx https://www.sqlskills.com/blogs/paul/how-expensive-are-page-splits-in-terms-of-transaction-log/]]>