BACPAC restore, dicas para melhorar a performance.

 É comum termos problemas com o tempo necessário para que um arquivo do tipo .bacpac seja restaurado independente de ser uma VM em seu PC ou Laptop ou em uma VM hospedada no Azure (CHE).

As ferramentas disponiveis para trabahar com o bacpac são as seguintes: SQLPackage e D365fo.tools

Ambas as ferramentas possuem variáveis para ajudar nesta tarefa de acelerar o tempo necessário para o restore...

Utilizar disco SSD durante o restore obviamente ajuda a melhorar o tempo de restore se comparado a um disco do tipo HDD. Não creio que você utilize disco do tipo HDD em seu PC ou Laptop hoje em dia, se este for o seu caso, você não tem salvação amigo... vai comprar um SSD pelamor!!!

Em VM´s no Azure, estratégias de gerenciamento de disco podem lhe ajudar a melhorar a performance de toda a VM. Após a criação da VM, com poucas mudança, você pode ter a flexibilidade de alterar o disco onde os arquivos do banco de dados ficam armazenados. Desta forma será possível conrverte-los entre SSD e HDD de acordo com a necessidade!

Tendo o hardware adequado você verá uma melhora no tempo de restore do bacpac com certeza!

Utilizando o SQLPackage, temos alguns comandos que podem ajudar nesta situação. um deles é o RebuildIndexesOfflineForDataPhase=True. Com este comando o rebuild dos indices acontece de forma offline. Sugiro obviamente que você faça seus testes! O ganho de tempo com este comando é visivel e significativo.

Outro comando usando o SQLPackage é o DisableIndexesForDataPhase=FALSE. Durante o restore notamos que o "disable index" é executado, logo após o bacpac começa a trabalhar com as tabelas e ao final os indices são habilitados novamente. Usando o comando DisableIndexesForDataPhase=FALSE a importação acontece sem o "disable" e o "enable" dos indices. Basicamente com este comando os indices não são recriados. As tabelas continuam com os indices, eles apenas não serão atualizados! Em meu teste o tempo de restore do bacpac caiu pela metade! Reforço que você DEVE fazer seus próprios testes e analisar o resultado com cuidado!

Outra alternativa é a opção "Delayed Durability". Esta opção está disponivel apenas quando o banco de dados já existe:

O Delayed Durability altera a forma como o SQL utiliza o arquivo de log, diminuindo a escrita em disco e com isso diminuido o I/O. Cuidado com esta opção pois ela pode causar falhas nos dados, se por qualquer razão o Windows se reiniciar durante o processo, você terá que reiniciar o restore.

Como esta opção somente fica disponivel para um banco que já existe, eu inicio o comando de restore e fico atendo ao momento em que o SQLPackge cria o banco no SQL Server, logo após a criação do banco de dados eu executo a seguinte query no SQL:

USE [master]
GO
ALTER DATABASE [DBName] SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE [DBName] SET DELAYED_DURABILITY = FORCED WITH NO_WAIT
GO

Existem outros comandos para o SQLPackage, veja mais deles neste link: SQL Pacakge

O D365fo.tools tem outros comandos que nos ajudam a melhorar o tempo de restore, um deles é o "Clear-D365TableDataFromBacpac". Com este comando você pode remover tabelas "indesejadas" antes de iniciar o restore caso você não tenha feito isso antes de exportar o arquivo .bacpac pelo LCS. Exemplo de uso deste comando: Clear-D365TableDataFromBacpac -Path "C:\Temp\preprod.bacpac" -TableName "*Staging*","BatchHistory","SYSDATABASELOG*", -ClearFromSource

Desta forma o bacpac a ser importado não terá estas tabelas, isso vai acelerar um pouco mais o processo!

Com as dicas acima o tempo de restore com certeza será menor!

Utilize as dicas acima por sua conta e risco, todos juntos ou um a um, faça seus próprios testes e analise os resultados em sua VM.

Boa sorte!

Export SSRS Reports as .RDL files

Today i was forced to export some old reports from one messed up SSRS report server. Security configurations of this SSRS were all crazy and no one could clarify why. I was able to see some reports but could not see other one's... i could download some... but could not open other's...

The internet is really usefull if you look for the right thing!

First, go to the GitHub here: https://github.com/Microsoft/ReportingServicesTools

Download the file into your server, go to the PowerShell and run the .\install.ps1.

After that you can run the following command to export all the reports as a .rdl file extension:

#------------------------------------------------------

#Prerequisites

#Install-Module -Name ReportingServicesTools

#------------------------------------------------------

#Lets get security on all folders in a single instance

#------------------------------------------------------

#Declare SSRS URI

$sourceRsUri = 'http://servername/ReportServer/ReportService2010.asmx?wsdl'

#Declare Proxy so we dont need to connect with every command

$proxy = New-RsWebServiceProxy -ReportServerUri $sourceRsUri

#Output ALL Catalog items to file system

Out-RsFolderContent -Proxy $proxy -RsFolder / -Destination 'C:\SSRSFiles' -Recurse

All done! Be happy!

SQL Server 2016 Developer Edition Download.

 Quer o SQL Server 2016 Developer Edition?...

Pega aqui ó:

https://download.microsoft.com/download/c/5/0/c50d5f5e-1adf-43eb-bf16-205f7eab1944/SQLServer2016-SSEI-Dev.exe

Restore não exibe porcentagem de progresso.

Este post é apenas para armazenar o conhecimento adquirido para casos futuros...!!!:

Fui incumbido de efetuar o restore de um banco de dados de 1.5TB em um ambiente que seria utilizado para testes diversos, trabalho normal e simples. Recebi todos os acessos e permissões corretas para tal, acessei os servidores e instancias necessárias para o processo de backup e restore, espaços em discos estavam ok, não havia impedimentos para realizar um trabalho simples, apenas demorado devido ao tamanho do banco!

Pois bem, backup feito corretamente, arquivos necessários movimentados para o diretório de destino, restore iniciado e ai PÁHHH, deu ruim... nenhum progresso era exibido, não adiantava usar o gráfico ou script, uma demora absurdamente anormal.

No Activity Monitor haviam locks ASYNC_IO_COMPLETION... obviamente não preciso reinventar a roda...

Antes de ir direto para a solução, eu verifiquei que as versões de SQL estavam diferentes entre os ambientes, sendo que o ambiente original era superior ao ambiente de destino. Neste caso apliquei o devido KB para igualar os ambientes.

Agora sim vamos à solução, sem reinventar a roda... uma pesquisa rapida me levou a este link:

http://mattslocumsql.blogspot.com/2014/02/why-are-my-database-restores-so-slow.html

E o link acima aponta pra este link:
https://techcommunity.microsoft.com/t5/Premier-Field-Engineering/How-and-Why-to-Enable-Instant-File-Initialization/ba-p/370329

Lendo o conteúdo dos dois links será fácil resolver o problema de o SQL não apresentar progresso no restore, seja via gráfico ou script, e também a lentidão absurda no processo de restore, criação de banco de dados novo ou crescimento do banco de dados!

Vivendo e aprendendo sempre, graças a Deus!

Unificar arquivos .MDF do SQL Server!

Recentemente atuei em um caso interessante, ao menos pra mim!

Um cliente me solicitou a migração de um ambiente de AX2012, isso obviamente inclui a migração do banco de dados.
Não sei por qual razão, mas no momento da criação o banco de dados foi criado com 08 arquivos de dados diferentes, todos eles com a extensão .MDF... E todos estes arquivos estavam armazenados no mesmo disco físico.

Ninguém soube me dizer o porque de este banco de dados ter sido criado desta forma... e o cliente não tinha a ideia de alocar cada arquivo em um disco físico diferente, então... porque ter tantos arquivos assim?

Resolvi então unificar todos eles em um unico .MDF... iniciei criando um banco de TESTE com 03 arquivos .MDF

E criei uma tabela simples com alguns registros...

Consultei os registros pra ter certeza de que foram criados:

Consultei a estrutura de banco pra saber se haviam registros em todos os 03 arquivos .MDF

Tendo certeza de que haviam registros em todos os arquivos comecei a remove-los um a um e verificando se os registros foram movidos do arquivo eliminado para o arquivo existente.
Primeiro removi o arquivo TESTE2.mdf.

Arquivo removido com sucesso, ao consultar os registros pude ver que todos ainda constavam no banco de dados e divididos entre os dois arquivos .MDF restantes. O próximo passo foi remover o arquivo TESTE1.mdf.

Agora meu banco de dados possui apenas 01 arquivos .mdf, consultando os registros vejo que todos os dados estão corretamente armazenados no banco, sem perda de dados. Conferindo a estrutura do banco confirmei que os demais arquivos foram removidos.

E com isso consegui eliminar os .MDF's desnecessários deste ambiente!

Após este trabalho em um banco de produção revise os índices para garantir o desempenho do banco de dados.

Não se esqueça de fazer um backup full de seu banco de dados antes de iniciar este trabalho!

Trace flag 9481 e Dynamics AX2012 R3 CU8.

Olá senhoras e senhores!

Hoje vou apenas compartilhar um fato ocorrido em um ambiente de AX2012 que ajudei a implementar!

O ambiente consiste em em 07 servidores, todos físicos, novos e muito mais do que suficientes para suas funções atuais, sendo que o mais fraco é um Dell six core com 32GB de RAM e discos SAS...

O ponto focal deste post é o AX2012 R3 CU8 e o SQL Server 2014...

Neste ambiente de AX tínhamos telas como as de "fatura de fornecedor" e a de "diário de faturas" que demoravam muito, mas muito mesmo para serem abertas... vale ressaltar que nestas telas haviam algumas alterações relacionadas apenas ao layout, nenhum código relacionado a consultas!

Outras telas sem custons sofriam com o mesmo problema.

As rotinas de manutenção dos bancos de dados estavam corretamente implementadas no SQL server de acordo com as boas práticas indicadas pelo time de PFE da Microsoft assim como diversos outros manuais disponíveis em blogs e principalmente no Partner Source!

Como não havia problemas na estrutura de servidores e nada relacionado a customizações passou-se a pesquisar sobre o funcionamento do SQL Server, analisando a forma como o SQL trabalha para exibir estas telas. Usando as ferramentas de monitoramento do SQL foi possível descobrir processos lentos nos planos de execução.

Pesquisando mais sobre "query plan" chegamos ao seguinte link: http://dba.stackexchange.com/questions/136768/query-wont-compile-run/136842

Também é possível obter mais detalhes neste link: https://support.microsoft.com/pt-br/help/2801413/enable-plan-affecting-sql-server-query-optimizer-behavior-that-can-be-controlled-by-different-trace-flags-on-a-specific-query-level

Breve detalhe sobre o Trace Flag 9481:
Use when running SQL Server 2014 with the default database compatibility level 120. Trace flag 9481 forces the query optimizer to use version 70 (the SQL Server 2012 version) of the cardinality estimator when creating the query plan.

Veja mais sobre Trace Flags para o Dynamics AX aqui.

Após habilitar este trace flag no SQL Server e limpar o cache do SQL Server a abertura das telas que apresentavam problemas de lentidão passou a ser instantânea.

Obviamente este procedimento foi testado em outros dois ambientes antes de entrar definitivamente em produção!

Devo dizer que toda a analise feita em ambiente de desenvolvimento nos levou ao ponto em que habilitar este flag foi necessário, e com um ótimo resultado. Tendo em mente que este ambiente de AX é diferente de outros, sugiro que se tiverem o mesmo problema, façam seus testes habilitando este trace flag, analisem os resultados e sigam em frente com a melhor decisão para seu ambiente!

Habilitar trace flags afeta todo o SQL Server, mas no nosso caso este SQL Server é 100% dedicado aos 03 bancos de dados do Dynamics AX. Caso seu SQL Server tenha outros bancos, são necessários vários outros testes para analisar o impacto nas demais aplicações!

Fica então a dica, eu testei no meu ambiente e aqui o resultado foi positivo!

O Blog agradece a ajuda de Otavio Anaga na criação deste post!

Até a próxima!

SPED ECF e Dynamics AX2012!

Olá!

Este post servirá para esclarecer alguma duvidas sobre o SPED ECF no Dynamics AX2012 e espero que ajude vocês em algo!

Temos agora um novo layout para o SPED ECF, este deve ser gerado utilizando o Management Reporter com CU15 e atualizado com o Hotfix 378213.

Estão ocorrendo problemas ao tentar utilizar este recurso tendo como banco de dados o SQL Server 2008 ou o 2008 R2.

Neste caso o MR2012 exige que o banco de dados seja o SQL server 2012 de acordo com o MR 2012 System Requirements.

Vale, e muito, lembrar que o SQL Server 2008, e também o 2008 R2, dependendo do service pack utilizado em seu ambiente, já não possui mais o suporte da Microsoft. Neste caso é necessário estudar o upgrade deste produto para as versões 2012, 2014 ou mesmo a 2016.

Em resumo, para utilizar o MR 2012 CU15 para  gerar o SPED ECF em seu novo layout é sim necessário que você tenha ao menos o SQL Server 2012 instalado!

Caso precisem de apoio no upgrade do SQL Server, tanto no licenciamento quanto no upgrade tecnico, por favor entrem em contato comigo e com certeza eu os ajudarei!

Até!

Dynamics Perf 2.0

Olá pessoal!

Seguem abaixo links sobre o DynamicsPerf versão 2.0:

DynamicsPerf 2.0 IS HERE !!

DynamicsPerf 2.0 Deployment Guide

DynamicsPerf 2.0 Installation for Dynamics AX

Setting up Windows Performance Monitor Templates

Aproveitem e usem esta ferramenta pois ela é de grande utilidade!

SQL Server 2014 e Dynamics AX2012!

Olá pessoal!

A Microsoft anunciou há alguns, vários, dias a compatibilidade entre o SQL Server 2014 e o Microsoft Dynamics AX2012!

Vejam a tabelinha abaixo:

Microsoft Product	Microsoft Dynamics AX Versions
SQL Server 2014 SP1	Dynamics AX 2012 R2 Cumulative update 8 and Dynamics AX 2012 R3 Cumulative update 9
.NET 4.6	Dynamics AX 2012 R2 Cumulative update 8 and Dynamics AX 2012 R3 Cumulative update 9

O documento AX 2012 System Requirements foi atualizado para contemplar esta mudança!

AX Performance Troubleshooting Checklist

Olá pessoal!

Seguem abaixo links para o post original relacionado a analise de performance:

Parte 01:
http://blogs.msdn.com/b/axsupport/archive/2014/09/05/ax-performance-troubleshooting-checklist-part-1a-introduction-and-sql-configuration.aspx

Parte 02:
http://blogs.msdn.com/b/axsupport/archive/2014/09/08/ax-performance-troubleshooting-checklist-part-2.aspx

Ótimo material de leitura para quem está enfrentando problemas de performance no AX!

Até a próxima!

Critical issue in SQL Server 2012 Service Pack 1 that could crash your SQL server.

Olá pessoal!

Essa se encaixa bem no ditado "antes tarde do que nunca"!!!

Ao aplicar o SP1 do SQL Server 2012 é possivel que ocorra um problema que causará um crash no serviço do SQL server.

Para solucionar este problema aplique o ultimo cumulative update do SQL Server 2012 SP1.

Para mais detalhes sobre este problema consultem o link fonte deste post!

Fonte: Blog Dynamics AX in the Field - MSDN

Como obter mais informações de uma mensagem de erro.

Pessoal, noite!!

Este post é somente para compartilhar o link de um post muito interessante, espero que seja útil a vocês!

Como Obter Mais Informações De Uma Mensagem De Erro.

Até próxima!

Dica do dia - Contadores para SQL Server

Pessoal, segue abaixo um material bem interessante onde é possível ver diversos contadores para SQL Server e entender qual a finalidade de cada um deles.

Contadores SQL Server

Indico também o acesso ao site da Quest (Dell) para mais materiais de estudo!

http://www.quest.com/techbrief/sql-server-perfmon-counters-poster811635.aspx

Espero que os ajude!