AMBIENTE HÍBRIDO – AZURE SQL DATABASE COM SQL SERVER ON-PREMISES

Olá Pessoal!

O processo de adoção de soluções na nuvem esta mais natural e transparente a cada dia, sendo assim, os clientes estão optando por estender o ambiente local (On-premises) e integrá-lo como parte da arquitetura Cloud cada vez mais, transformando em uma solução híbrida. Esse tipo de solução pode ser alcançada de maneiras diferentes dependendo do tipo de plataforma de dados escolhida no ambiente da nuvem, nesse artigo vamos abordar o funcionamento de uma solução entre Azure SQL Database (Platform as a Service) e o SQL Server 2017 On-Premises.

Temos o seguinte cenário para trabalhar, o cliente deseja migrar o banco de dados SQL Server para o Azure SQL Database, levando em consideração principalmente o custo/benefício do serviço, além disso tem intenção de manter os dados replicados em sua instância de origem no SQL Server 2017 On-Premises, funcionando como uma espécie de Disaster Recovery.

Essa integração entre o SQL Database e o SQL Server depende do serviço Azure SQL Data Sync que está incorporado no Azure SQL Database. O Azure SQL Data Sync pode ser utilizado para distribuição de dados entre SQL Server, Azure SQL VM e Azure SQL databases, tanto unidirecional quanto bidirecional. Para nosso cenário, utilizaremos esse serviço para sincronização dos dados entre o Azure SQL Database e SQL Server on-premises.

Veja na topologia abaixo o modelo que utilizaremos:

A primeira etapa dessa solução envolve a migração da base para o Azure SQL Database, no qual pode ser feito através do Microsoft Data Migration Assistant (DMA). Vou considerar que essa etapa foi concluída com sucesso e sem restrições, sendo assim, o ambiente no Azure (PaaS) já está preparado.

Veja na imagem acima que uma das opções disponíveis no menu de configurações do Azure SQL Database é o “Sync to other databases” e após acessar essa opção pode ser visto as categorias “Sync Group” e “Sync Agent“.

O Data Sync é baseado no conceito do Sync Group, que é o grupo de bases que você deseja sincronizar. Dentro do Sync Group é definido a base que servirá como “Hub” e as restantes são definidas como membro, dessa forma a comunicação ocorre apenas entre o “Hub” e os membros individuais.

Algumas considerações importantes:

  • A base de dados “Hub” precisa ser um Azure SQL Database;
  • As bases de dados member podem ser SQL Databases, on-premises SQL Server databases ou instâncias SQL Server em Azure virtual Machines;
  • A base de dados Sync contém o metadado e log do Data Sync, sendo necessário ser um Azure SQL Database localizado na mesma região que a base de dados “Hub”;
  • Se uma base de dados on-premises for definida como membro, obrigatoriamente deve ser instalado e configurado o “Local Sync Agent“.

Como pode ser visto nas considerações, em nosso cenário será necessário instalar o “Local Sync Agent“, entretanto iniciaremos pela configuração do “Sync Group“.

Selecione a opção de “New Sync Group” dentro do menu “Sync to others databases“, como pode ser visto na imagem anterior. Deve ser preenchido o nome do “Sync Group“, a base de dados que irá receber os metadados, sendo que, é recomendado que uma nova base seja criada exclusivamente para armazenar esses dados, também deve ser selecionado na opção “Automatic Sync“, que define a frequência de atualização dados dados e por último, o “Conflict Resolution” que tem duas opções, “Hub Win” e “Member Win“, caso seja escolhido o primeiro, se algum conflito ocorrer na sincronização os dados da origem (“Hub”) substituem os dados conflitados no destino (“Member”), na segunda opção, ocorre exatamente o inverso.

Após finalizar essa etapa, o Azure vai iniciar o processo de implantação do “Sync Group” e em seguida avançar para a inclusão dos membros no menu “Add sync members“. Nessa etapa o usuário e senha de acesso devem ser preenchidos para a base de dados atual selecionada como “Hub“. Logo abaixo temos disponível a seleção do “Member Database“, que pode ser um Azure Database ou um On-Premises Database, para nosso cenário irei selecionar a segunda opção.

A primeira opção dentro da etapa do “Configure On-Premises” é para fazer a configuração do “Sync Agent Gateway“, sendo assim, vemos criar um novo e para isso devemos fazer o download do SQL Azure Data Sync Agent. A instalação é bem simples e apenas requer um usuário com privilégios para rodar o serviço no Windows.

Após a instalação, devemos retornar ao Azure e preencher o nome do agente para que possa ser gerado a chave de registro do “Sync Agent“.

Retorne ao “Sync Agent” e selecione “Submit Agent Key“, em seguida preencha o “Agent Key” com a chave copiada e também as credenciais de acesso do Azure SQL Database criado anteriormente para os metadados.

O próximo passo será registar o acesso ao SQL Server On-Premises através da opção “Register” no “Sync Agent“.

Uma vez que as configurações foram finalizadas, podemos retornar ao Azure e selecionar “OK” no menu “Select Sync Agent” e retornar ao “Configure On-Premises“. Seguiremos para a opção “Select the Database“, na qual temos que preencher o nome no campo “Sync Member Name“, selecionar o “Sync Agent” recém configurado e o “Sync Directions“. O “Sync Directions” determina a direção que os dados serão sincronizados, no nosso caso utilizaremos o “From the Hub“, ou seja, a base de dados no Azure SQL Database que está configurada como “Hub” será a origem dos dados a serem sincronizados.

Finalize essa configuração através do botão “OK” no menu “Select the Database“, “Configure On-Premises” e “Select sync members“, em seguida o Azure vai iniciar as implementações. Por último, iremos ao menu “Configure sync group” para selecionar as tabelas que serão sincronizadas. Repare que existe um alerta informando que apenas as tabelas com chave primária são suportadas, felizmente a tabela “SalesOrderDetailEnlarged” atende esse requisito.

Após salvarmos a configuração, o Azure irá processar as alterações e retornar para o menu inicial do “Sync to other databases“.

Ao verificar via SSMS as bases do Azure SQL Database, perceba que além da “AventureWorks2017” que já existia, foi adicionada a base de dados “dbsyncmetadata” com os metadados, também foram criados novas tabelas de apoio da solução dentro da base “AventureWorks2017“. Essas mesmas tabelas foram criadas no SQL Server On-Premises.

Agora a solução para atender o cliente está pronta, restando apenas testar o seu funcionamento. Podemos acessar o “Sync Group” e acompanhar os logs para identificar as notificações de erro e sincronização.

Apesar de serem etapas simples, existem muitas limitações que impossibilitam que essa solução seja utiliza para qualquer cenário, é importante que seja feita a leitura de toda documentação do produto, assim como, os devidos testes antes da utilização em produção.

Seguem as referências:

https://docs.microsoft.com/pt-br/azure/sql-database/sql-database-get-started-sql-data-sync

https://docs.microsoft.com/pt-br/azure/sql-database/sql-database-sync-data

https://azure.microsoft.com/pt-br/blog/azure-sql-hybrid-data-movement/

Até a próxima!

Anúncios

BACKUP AUTOMATIZADO DO SQL SERVER COM AZURE VIRTUAL MACHINE

Olá Pessoal!

Um dos benefícios de criar uma instância do SQL Server em uma máquina virtual no Microsoft Azure são as integrações nativas disponíveis no painel do Azure, como é o caso do recurso de Backup Automatizado (Automated Backup). Vamos explorar melhor esse recurso com a demonstração abaixo utilizando uma máquina virtual com o SQL Server 2017.

O SQL Server também está disponível no Azure como IaaS (Infrastructure as a Service), sendo assim, existem alguns modelos para contratação e dentre eles, a opção de criar a máquina virtual a partir de uma imagem que contém a edição desejada do produto.

No processo de criação da máquina virtual, diversos itens devem ser preenchidos até chegar a etapa de configuração do SQL Server, na qual iremos configurar o Backup Automatizado pelo painel do Azure.

Antes de avançar no recurso do Backup Automatizado, vamos relembrar quais opções a Microsoft disponibiliza atualmente para realização do backup em instâncias SQL Server rodando em Azure Virtual Machines (IaaS):

Como foi citado acima, é possível que backups regulares do banco de dados sejam configurados utilizando o armazenamento do Azure Blob Storage, entretanto, para que esse recurso funcione é necessário que a extensão do SQL Server IaaS Agent esteja instalada no host que contém a instância do SQL Server e essa extensão só é compatível para deploys de VMs a partir das imagens disponíveis na galeria de recursos do Azure. A extensão do SQL Server IaaS Agent não será compatível se você instalar o SQL Server em uma máquina virtual do Windows Server somente com o sistema operacional ou se for utilizado um VHD de uma VM do SQL Server personalizada.

Veja na imagem abaixo a extensão SqlIaasExtension.

Voltando a tela de configuração do Backup Automatizado, essa opção deve ser habilitada no menu de configurações do SQL Server ainda no processo de setup do host.

É possível perceber que as seleções disponíveis são bem simples e existe uma opção bem relevante, a “Janela de tempo de backup (horas)”, na qual é definido o tempo máximo disponível para que o backup seja realizado.

Uma vez que a configuração foi concluída, um resumo é apresentado antes de iniciar o processo de criação do host, que deve demorar alguns minutos. Note que uma nova conta de armazenamento foi criada no processo de configuração do host.

Com a máquina criada e a instância do SQL Server em funcionamento, é só uma questão de tempo até que recurso do Backup Automatizado comece a realizar os backups e armazenar os arquivos no Azure Blob Storage. Para verificar os arquivos de backup, vá até a conta de armazenamento utilizada no processo de criação do host e selecione a opção do armazenamento de Blobs.

O contêiner com o nome “backupcontainer” será criado no processo de configuração do Backup Automatizado, é nele que os arquivos de backup do SQL Server são armazenados.

Para leitura dos dados do Azure Storage também pode ser utilizado a ferramenta Microsoft Azure Storage Explorer, que permite uma melhor visão e gerenciamento do armazenamento.

Vamos ao SSMS para buscar através de uma Query as informações dos backups que foram realizados até o momento, veja na imagem abaixo as informações relacionadas ao armazenamento.

Caso deseje alterar as configurações do Backup Automatizado após a host estar criado, basta acessar a opção “Configuração do SQL Server” no painel da máquina virtual.

Ao acessar esse menu, uma série de opções de configuração da instância do SQL Server estarão disponíveis e dentre elas, o Backup Automatizado.

 

Existem limitações e requisitos não abordados aqui que devem ser atendidos para utilização do Backup Automatizado, vejam na documentação oficial todos esses importantes pontos antes da implementação.

Informações adicionais:

https://docs.microsoft.com/pt-br/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-server-iaas-overview#get-started-with-sql-vms

https://docs.microsoft.com/pt-br/sql/relational-databases/backup-restore/sql-server-backup-and-restore-with-microsoft-azure-blob-storage-service?view=sql-server-2017

Até a próxima!

.NET FRAMEWORK RUNTIME FATAL ERROR

Olá Pessoal!

Faz pouco tempo que passei por um problema em uma implementação e tive que recorrer ao suporte do produto junto a Microsoft, vou compartilhar esse caso com vocês.

Durante o processo de teste e ajuste de hardware após a implantação de um ambiente SQL Server 2017 utilizando Always On Availability Groups com dois nós, foi observado failovers ocorrendo de forma inesperada entre os nós. Ao analisar o error log do SQL Server, a seguinte mensagem foi apresentada:

Acontece que o erro gerado causou crash na instância do SQL Server e o failover automático foi acionado imediatamente, por isso da transição das roles entre os nós inesperadamente. Apesar de saber o motivo do failover, ainda não sabíamos por que um erro no componente .NET Framework runtime causou uma reinicialização no serviço do SQL Server e se poderia ocorrer novamente, impactando no ambiente que iria para produção.

Optei por abrir um chamado na Microsoft para apoio na identificação da causa raiz do problema, buscando evitar dessa forma que o mesmo ocorra novamente. Após a solicitação inicial do chamado, o analista responsável pelo ticket solicitou uma série de informações complementares para esclarecer melhor o ocorrido, assim como, entender em quais circunstâncias o Stack Dump foi gerado.

Após verificar os logs do SQL Server e o Dump gerado, o analista percebeu um detalhe relacionado a configuração de hardware. No dia anterior ao ocorrido, foi feito um upgrade de hardware nos hosts com as instâncias do SQL Server, tanto o processador quanto a memória foram alterados utilizando o VMware Hot-Add. Veja abaixo:

Processador e Memória antes

Processador e Memória depois

Foi concluído que durante o evento do crash, o SQL Server detectou 16 sockets com 1 core per socket e 1 logical processor per socket e com um total de 16 logical processors, além de 128GB Ram. A equipe de suporte apontou que já observou alguns casos com esse cenário, no qual o SQL Server falha ao detectar desalinhamento com os processor cores. O crash dump gerado após a falha informa que o erro ocorreu devido a Access Violation. Access Violation conceitualmente ocorre quando um programa executa uma ação em um endereço de memória, no entanto, essa ação não é permitida. A página de memória será configurada com a opção de proteção de memória adequada durante a alocação. Se um aplicativo acessar um endereço de memória que não esteja alinhado com a proteção de página para essa memória, será lançada uma exceção de Access Violation.

Realmente esse caso foi uma exceção e não voltou a ocorrer, atualmente o ambiente está totalmente estável.

Até a próxima!

SQL SATURDAY #792 BRASILIA 2018

Olá Pessoal!

O já tradicional SQL Saturday está de volta a Brasília em mais uma edição recheada de boas palestras com os melhores profissionais de plataforma de dados. Lembrando que este evento é de graça!

Esse ano teremos também uma Pós Conferência – Treinamento com o Fabiano Amorim.

Espero vocês lá, não percam essa oportunidade, mais informações acessem:

http://www.sqlsaturday.com/792/eventhome.aspx

https://www.eventbrite.com.br/e/pos-sqlsat792-investigando-problemas-de-cpu-no-sql-server-tickets-47260300832

Até a próxima!

ALTERNATIVA PARA O SHRINK NO SQL SERVER

Olá Pessoal!

Faz um tempo que não público nada e isso se deve as recentes mudanças profissionais que consumiram meu tempo por completo. Para poder retomar o ritmo, vou compartilhar com vocês uma estratégia que utilizei recentemente para reduzir o tamanho do Data File de uma determinada base através do Shrink, mas contornando alguns impactos negativos que essa ação normalmente causa na fragmentação dos índices.

A operação de Shrink no SQL Server reduz o tamanho de um arquivo de dados ou log, podendo retornar esse espaço ao File System.

Veja mais detalhes na documentação oficial da Microsoft:

https://docs.microsoft.com/pt-br/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql?view=sql-server-2017

O motivo que fez necessário a execução do Shrink no Data File, foi devido a uma tabela excluída recentemente que gerou uma grande quantidade de espaço sem uso no Data File e necessitávamos retornar ao File System esse espaço, além de reduzir a base para um tamanho realista.

Como sabemos, o operação do Shrink contribui para as fragmentações externas dos índices, ou seja, quando a ordem lógica das páginas de dados não batem com sua ordem física. A operação do Shrink localiza a maior página de dados alocada no arquivo baseado no GAM (Global Allocation Map) e a move para o mais na frente possível sem considerar a qual objeto aquela página de dados pertence. É recomendado evitar a operação de Shrink a menos que seja absolutamente necessário.

Além disso, é melhor aplicar a operação de Reorganize nos índices ao invés do Rebuild após a operação do Shrink. O Rebuild de um índice cria uma outra cópia do índice, o que acaba aumentando o tamanho do Data File e derruba a proposta do Shrink.

Antes de executar a operação de Shrink no Data File, lembrei de um procedimento que vi há muito tempo atrás recomendando a utilização de novos Filegroups para reduzir o tamanho da base de forma similar a operação de Shrink, mas sem causar fragmentação após sua execução. Vamos acompanhar a demonstração abaixo para entender melhor o conceito.

Para demonstração foi utilizado o SQL Server 2017 (RTM-CU8) com a base AdventureWorks2017, além de ter sido aplicado um script para aumentar o tamanho de suas tabelas, os links para download estão a seguir:

https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

https://www.sqlskills.com/blogs/jonathan/enlarging-the-adventureworks-sample-databases/

Em todos os passos da demostração foi utilizado apenas a tabela “Sales.SalesOrderDetailEnlarged”, veja a estrutura.

A DMV “sys.dm_db_index_physical_stats” com a opção “DETAILED” aplicada para tabela permite que todo índice seja verificado, trazendo resultados mais precisos relacionados a analise de fragmentação. Veja na imagem que a coluna “avg_fragmentation_in_percent” está com valores baixos.

A tabela tem mais de 4 milhões de registros.

Através da consulta na tabela de sistema “sys.database_files”, é possível ver em nosso exemplo que existe cerca de 1 Gb no Data File livre e será esse espaço disponível que reduziremos.

O comando “DBCC SHRINKFILE” está recebendo o nome da base e o tamanho alvo da operação, que está definido para esse exemplo como 5 Mb.

Veja que após a execução do Shrink no Data File a fragmentação dos índices aumentou consideravelmente.




Agora vou demonstrar a outra estratégia com o uso de um novo Filegroup no processo. Para esse exemplo a base foi restaurada ao ponto inicial, não sendo afetada pelo Shrink executado anteriormente.

O script apresentado na imagem abaixo cria um novo Filegroup com o nome SECONDARY e o associa a um novo Database File “AdventureWorks2017_data02.ndf”.

O próximo passo é mover os índices para o novo Filegroup “SECONDARY”, sendo necessário realizar a sua recriação.

Ao verificar novamente as informações de espaço disponível nos arquivos, veja como a estrutura está distribuída.

Na imagem abaixo é mostrado o resultado da execução da operação de Shrink e apenas o Data File afetado com tamanho reduzido, conforme o esperado.

Na DMV “sys.dm_db_index_physical_stats” a fragmentação dos índices está com valores bem baixos, não tendo sido afetada pelo procedimento de Shrink anterior.

Por último, podemos eliminar o antigo arquivo do Filegroup “PRIMARY” que na teoria não tem nenhuma página de dados alocada nele, entretanto, o arquivo de dados principal não pode ser nunca excluído, isso é devido a estruturas especiais que existem nele e não podem ser realocadas, sendo assim, essa operação de exclusão de arquivos só pode ser feito nos demais casos, com novos arquivos e Filegroups.

Como pode ser visto, o procedimento alternativo a operação de Shrink envolve mais passos e com certeza mais esforço considerando um ambiente real com dezenas de objetos, entretanto, em um cenário controlado a necessidade de um procedimento de Shrink no Data File é muito baixa, sendo aplicado em situações bem específicas, então nesse caso vale a pena o empenho de recriar índice por índice, evitando a fragmentação forçada.

Até a próxima!

USANDO O SSRS PARA MONITORAR CONTENÇÃO DE I/O NO SQL SERVER

Olá Pessoal!

Feliz Ano Novo…Para começar bem o ano de 2018, vou compartilhar um relatório muito útil no trabalho do dia a dia de monitoramento do ambiente, um dashboard de monitoramento das contenções de I/O das instâncias SQL Server, com comparação de quantidade de notificações por semana.

Para criação do relatório foi utilizado o Reporting Services 2016 e consultas na tabela do error log para filtrar as informações. No ambiente que foi implantado essa solução, temos uma instância que extrai as informações necessárias para relatórios de todas as demais instâncias e dessa forma é possível consolidar os dados em apenas um repositório, utilizando para consultas, nesse caso os dados da tabela de error log.

Siga as etapas abaixo:

1 – Nas instâncias que deseja coletar as informações, a consulta abaixo deve ser utilizada em cada arquivo do error log.

INSERT INTO tb_IOWarningResults
EXEC xp_readerrorlog 0, 1, N'taking longer than 15 seconds';

No exemplo acima estou inserindo os dados de apenas um arquivo do error log em determinada tabela, sendo que, a busca filtra apenas a string com a mensagem enviada ao SQL Server. A mensagem que está sendo buscada é a seguinte:

Exemplo:

SQL Server has encountered x occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [C:\MSSQL\MSSQL.1\MSSQL\Data\data.mdf] in database [database]. The OS file handle is 0x00000000. The offset of the latest long I/O is: 0x00000000000000

Não vou me aprofundar no assunto, mas basicamente a mensagem informa que o subsistema de disco não está operando de forma satisfatória e alguma operação está sendo impactada devido ao tempo de resposta de IO acima de 15 segundos.

O artigo a seguir auxilia no troubleshooting e entendimento dessa contenção de IO: https://blogs.msdn.microsoft.com/sqlsakthi/2011/02/09/troubleshooting-sql-server-io-requests-taking-longer-than-15-seconds-io-stalls-disk-latency/

2 – Uma vez que os dados foram inseridos em tabelas (temporárias ou não) em cada instância, seja através de uma chamada remota ou agendamento (job), é necessário fazer a leitura das tabelas e para essa tarefa eu utilizei uma View intermediária para consolidar todas as consultas com Linked Server, veja.

CREATE VIEW [dbo].[VW_MONITOR_LOG_EVENT]
AS

SELECT 'HOST1' AS SERVER,LogDate AS LogDate, LogText COLLATE Latin1_General_CI_AI AS LogText
FROM [HOST1].master.dbo.tb_IOWarningResults

UNION ALL

SELECT 'HOST2' AS SERVER,LogDate AS LogDate, LogText COLLATE Latin1_General_CI_AI AS LogText
FROM [HOST2\MSSQLSERVER01].master.dbo.tb_IOWarningResults

3 – Após consolidar os resultados em um grande “tabelão”, apliquei alguns tratamentos nos dados criando uma nova view, veja.

CREATE VIEW [dbo].[VW_VIEW_LOG_EVENT_INFORMATION]
AS
SELECT [SERVER],convert(date,[LogDate]) as [LogDate],
substring(logtext,charindex('I/O',logtext,1),54) as [LogText],
CONVERT(BIGINT,LEFT(subsrt, PATINDEX('%[^0-9]%', subsrt + 't') - 1)) as QTD_OCORRENCIAS
FROM (
SELECT [SERVER],convert(date,[LogDate]) as [LogDate],[LogText],subsrt = SUBSTRING(logtext, pos, LEN(logtext))
FROM (
SELECT [SERVER],convert(date,[LogDate]) as [LogDate],[LogText], pos = PATINDEX('%[0-9]%', logtext)
FROM VW_MONITOR_LOG_EVENT with (nolock)
) d
) t

4 – Com o conjunto de dados obtido é possível montar uma série de relatórios diferentes, mas eu optei por fazer uma comparação entre a semana atual e semana anterior, agregando os valores por instância, sendo assim, a consulta abaixo foi utilizada.

SELECT VW.[SERVER],CONVERT(VARCHAR(92),VW.[LogText]) AS [LogText],
SUM(VW.QTD_OCORRENCIAS) AS QTD_OCORRENCIAS_ULTIMOS_7_DIAS,
VW2.QTD_OCORRENCIAS_SEMANA_ANTERIOR
FROM MASTER.DBO.VW_VIEW_LOG_EVENT_INFORMATION AS VW
JOIN (SELECT [SERVER],SUM(QTD_OCORRENCIAS) AS QTD_OCORRENCIAS_SEMANA_ANTERIOR
FROM MASTER.DBO.VW_VIEW_LOG_EVENT_INFORMATION
WHERE LogDate > convert(date,getdate()-14)
and LogDate convert(date,getdate()-7)
GROUP BY VW.[SERVER],VW.[LogText],VW2.QTD_OCORRENCIAS_SEMANA_ANTERIOR

O resultado esperado deve ser como nesse exemplo abaixo.

No próximo passo iniciarão etapas a serem realizadas no Reporting Services.

5 – Vou pular as etapas de configuração inicial do Reporting Services e avançar para criação de um novo Data Source dentro do Reporting Services que irá conectar na instância “central” que contém as consultas montadas anteriormente. Veja o exemplo abaixo, onde uma simples conexão com o SQL Server é criada.

6 – Deve ser criado na sequencia o Data Set que irá conter a consulta com o conjunto de dados que será utilizado relatório. Através da pagina web do Reporting Services o Report Builder será iniciado, como pode ser visto na imagem a seguir.

7 – Em vez de um tradicional relatório paginado, criaremos um Mobile Report. Para aqueles que não conhecem esse recurso, ele é otimizado para dispositivos móveis e conectados a dados locais, com uma variedade de visualizações de dados.

8 – Com o SQL Server Mobile Report Publisher aberto podemos fazer finalmente a criação do dashboard, mas primeiro temos que nos conectar ao Data Set criado anteriormente. Navegue até a aba de dados e selecione opção de adição de dados, veja abaixo.

A imagem acima foi capturada a partir da edição do relatório já montado.

9 – Uma vez conectado, iniciaremos o layout do dashboard. Utilizaremos 3 layouts no painel, sendo o primeiro o que está marcado na imagem abaixo. Arraste e o coloque na mesma posição, utilizando a metade horizontal do painel, sem modificar a quantidade de linhas e colunas na grade.

10 – Em seguida arraste 2x o gráfico de pizza utilizando o espaço restante no painel, veja na imagem abaixo.

11 – Volte para a aba de configuração de dados para que cada elemento do relatório possa ser configurado. Para o primeiro elemento, siga conforme a imagem abaixo a configuração das propriedades. Deve ser alterado a fonte de dados e adicionado uma nova coluna para que seja possível fazer uma comparação de quantidade de dados entre períodos, os demais ajustes já devem vir preenchidos.

12 – Os ajustes finais na primeira parte do painel deve ser feita na aba de layout, o modelo sugerido deve ser como na imagem abaixo.

13 – Ainda na aba de layout, os gráficos de pizza devem ser alterados para apresentar a estrutura em linhas, as alterações na fonte de dados deve ser feita na aba de dados. Como cada gráfico irá apresentar a somatória de ocorrências da mensagem do error log, será feito a comparação entre os valores da semana atual e anterior. Repare nos campos destacados a opção que deve ser selecionado na imagem abaixo, para o segundo gráfico de pizza deve ser o inverso a seleção da coluna.

14 – Volte na aba de design e faça qualquer ajuste final pendente, o modelo do relatório construído deve estar conforme a imagem abaixo.

15 – Uma vez concluído a construção do relatório é o necessário fazer a publicação para dentro da estrutura do Reporting Services. Esse processo é relativamente fácil e intuitivo, deve ser selecionado a opção para salvar e conectar ao host do Reporting Services, em seguida navegar nos diretórios. Depois de salvo o relatório mobile pode ser carregado pelo navegador, veja na imagem abaixo.

Pronto, concluímos o nosso relatório mobile e ele está pronto para ser acessado através de diversas plataformas. Além do acesso tradicional pelo endereço do relatório no Reporting Services, é possível acessá-lo pelo aplicativo do Power BI que pode ter seu download feito na Apple Store e Google Play. O aplicativo é grátis e dentre suas funcionalidades, é possível conectar ao seu servidor do Reporting Services localmente e consultar os relatórios mobile disponíveis, veja na imagem abaixo.

Caso tenham sugestões para otimização do processo que coleta os dados ou até no design do relatório, por favor, deixem nos comentários.

Obs: Alguns dados utilizados para realização dessa demonstração de criação de relatórios tiveram que ser ofuscados.

Até a próxima!

Configurando o DTC no SQL Server

Olá Pessoal!

Nessa última semana participei de uma migração de infraestrutura de um sistema de gerenciamento de serviço, basicamente o host de banco de dados (SQL Server 2016) seria alterado para um novo em outra localidade.

O que parecia ser um procedimento padrão, demandou um trabalho adicionado devido ao MSDTC (Microsoft Distributed Transaction Coordinator) que estava configurado no antigo ambiente e era necessário para o funcionamento de um dos módulos da aplicação. Como o antigo ambiente foi absorvido sem documentação, a necessidade de configuração do DTC só foi percebida depois que a aplicação retornou o seguinte erro ao tentar iniciar:

A mensagem informa que a base especificada não suporta transações XA. Ao pesquisar por essa mensagem foi possível fazer a relação com o DTC, afinal existe uma opção para habilitar as transacoes XA dentro das propriedades do DTC.

Reproduzi as mesmas configurações do DTC que existiam no antigo ambiente para novo, mas mesmo assim a aplicação ainda apresentava erro e nenhuma estatística de transação era gerada. As configurações do DTC podem ser vistas acessando o menu de Component Services dentro do Windows Server:

Navegando nos demais sites relacionados a consulta inicial, foi possível ver alguns procedimentos adicionais que deveriam ser executados no SQL Server, além da configuração já feita no DTC no SO. No site da IBM abaixo, por exemplo, é apresentado um passo a passo do que deve ser feito bem simples, pois o suporte das transações XA é feito pelo driver JDBC para SQL Server, permitindo dessa forma o inicio das operações com transações distribuídas necessário para o funcionamento da aplicação.

https://www.ibm.com/support/knowledgecenter/en/SSFTN5_8.5.5/com.ibm.wbpm.imuc.ebpm.doc/topics/db_xa_nd_aix.html

Em determinado ponto do passo a passo apresentado no site da IBM, é feito referencia aos arquivos sqljdbc_xa.dll e xa_install.sql. Esses arquivos podem ser obtidos através do driver JDBC para SQL Server, segue o link abaixo para download:

https://www.microsoft.com/en-us/download/details.aspx?id=55539

Dentro dos arquivos extraídos terá um diretório com o nome “XA”, com uma breve navegação sera possível encontrar os arquivos sqljdbc_xa.dll e xa_install.sql. Os passos a seguir devem feitos conforme informado no site da IBM, são eles:

  • Copy the sqljdbc_xa.dll file from the JDBC unarchived directory to the Binn directory (for a default SQL Server install, the location is C:/Program Files/Microsoft SQL Server/MSSQL10_50.MSSQLSERVER/MSSQL/Binn) of SQL Server computer. If you are using XA transactions with a 32-bit SQL Server, use the sqljdbc_xa.dll file in the x86 folder, even if the SQL Server is installed on a x64 processor. If you are using XA transactions with a 64-bit SQL Server on the x64 processor, use the sqljdbc_xa.dll file in the x64 folder.
  • Run the xa_install.sql database script on SQL Server. For example; from the command prompt, run sqlcmd -i xa_install.sql. This script installs the extended stored procedures that are called by sqljdbc_xa.dll. These extended stored procedures implement distributed transaction and XA support for the Microsoft SQL Server JDBC Driver. You will need to run this script as an administrator of the SQL Server instance. You can ignore errors about unable to drop procedures that don’t exist.
  • Open the SQL Server Management Studio to locate the security folder under the master database. To grant permissions to a specific user to participate in distributed transactions with the JDBC driver, add the user to the SqlJDBCXAUser role in the master database (for example, for a Lombardi user add master database in User mappings and check SqlJDBCXAUser role).

Após concluir os passos acima a aplicação subiu sem problemas e imediatamente as estatísticas de transações começaram a ser carregadas:

Até a próxima!