none
Merge de Banco de Dados RRS feed

  • Pergunta

  • Pessoal, bom dia.

    Nosso DAX2009 anda mal das pernas com a performance...às vezes leva mais de 06 minutos para faturar uma NF.
    Temos algumas customizações que sei que atrapalham um pouco a performance, mas não creio que sejam as responsáveis.
    Ao final de cada dia, as coisas ficam piores, temos mais de 30 lojas e todas faturam ao mesmo tempo, mas não acredito que isto possa causar o consumo de quase 100% do banco de dados.
    Temos hoje 04 AOS's para as 30 lojas do grupo.
    Nosso BD está configurado da seguinte forma:


    Windows Server 2008 R2 SP1
    Intel Xeon X5660 2.80Ghz (08 Processors) 64 Bit
    50GB RAM

    SQL Server 2008 R2

    A minha pergunta é: Para dividir a carga no banco de dados, é possível que o AX trabalhe com o SQL em replicação do tipo MERGE ?

    Abs a todos.
    segunda-feira, 2 de dezembro de 2013 13:14

Respostas

  • Mateus,

    Tínhamos problema parecido e a correção foi alterar a classe que executa o faturamento da Nota Fiscal, como segue:

    Classe: SalesFormLetter_Invoice

    Método: updateNow

    Localize este trecho de código:

    if (BrazilParameters::isEnabled())
        {
            TaxNumValidate_BR::postingSalesLegalTxt(); 
            transitDeposit = salesOperationType.DlvTransitDeposit;

            if (transitDeposit != "")
            {
                transitItemJournal = new DlvTransitInventControl_BR(custInvoiceJour.InvoiceId);
            }
        }

    Insira o parâmetro abaixo:

    if (BrazilParameters::isEnabled())
        {
            TaxNumValidate_BR::postingSalesLegalTxt(salestable.SalesId); 
            transitDeposit = salesOperationType.DlvTransitDeposit;

            if (transitDeposit != "")
            {
                transitItemJournal = new DlvTransitInventControl_BR(custInvoiceJour.InvoiceId);
            }
        }

    Faça na sua base de homologação e veja se o desempenho melhora.



    Josemar



    Marque se a resposta for útil







    • Marcado como Resposta matfurrier terça-feira, 3 de dezembro de 2013 18:51
    terça-feira, 3 de dezembro de 2013 15:59

Todas as Respostas

  • Mateus, tudo bem? Geralmente, replicação não deixa o banco mais rápido. Deixa mais confiável. Pense que todo trabalho que o SQL for fazer, será dobrado. Agora, eu já vi customização estragar os processos padrão de forma absurda. Portanto, se me dissessem que uma custom provoca este tipo de lentidão no processo de faturamento, eu acreditaria. Mas enfim, acredito que antes de trabalhar com instãncias do SQL, você poderia ligar o SQL Profiler e faturar manualmente uma ordem de venda. Aí você consegue ver Locks nas tabelas, tempo de query, consultas otimizadas dentre outros. Muito provável que você consiga resolver seus problemas OU com a melhoria da custom, OU com indexação (ou reindexação) do seu banco de dados. Abraço.

    Gustavo Bagno E. da Silva

    segunda-feira, 2 de dezembro de 2013 21:12
  • Olá Gustavo, tudo certo ?

    Então, eu tenho "quase" certeza de que as customizações estão matando o BD, mas, estamos com sérios problemas com o parceiro para corrigir isto.
    No DAX2009, temos muitas views customizadas, o processo de multisite também gera sobrecarga.
    O que eu acho mais estranho é, que, em alguns momentos o sistema está super rápido, NFs faturadas em 30 segundos...em outros, elas faturam em 7 minutos.
    Eu vou fazer o que você me recomendou e tentar levantar as áreas onde estamos castigando o banco e qual processo.
    Volto a falar contigo em breve.
    Se tiver mais alguma sugestão, agradeço muito.
    Abraços.

    Mateus.

    terça-feira, 3 de dezembro de 2013 10:10
  • Mateus,

    Tínhamos problema parecido e a correção foi alterar a classe que executa o faturamento da Nota Fiscal, como segue:

    Classe: SalesFormLetter_Invoice

    Método: updateNow

    Localize este trecho de código:

    if (BrazilParameters::isEnabled())
        {
            TaxNumValidate_BR::postingSalesLegalTxt(); 
            transitDeposit = salesOperationType.DlvTransitDeposit;

            if (transitDeposit != "")
            {
                transitItemJournal = new DlvTransitInventControl_BR(custInvoiceJour.InvoiceId);
            }
        }

    Insira o parâmetro abaixo:

    if (BrazilParameters::isEnabled())
        {
            TaxNumValidate_BR::postingSalesLegalTxt(salestable.SalesId); 
            transitDeposit = salesOperationType.DlvTransitDeposit;

            if (transitDeposit != "")
            {
                transitItemJournal = new DlvTransitInventControl_BR(custInvoiceJour.InvoiceId);
            }
        }

    Faça na sua base de homologação e veja se o desempenho melhora.



    Josemar



    Marque se a resposta for útil







    • Marcado como Resposta matfurrier terça-feira, 3 de dezembro de 2013 18:51
    terça-feira, 3 de dezembro de 2013 15:59
  • Olá Josemar, tudo bom ?

    Ao inserir este parâmetro no código, me retorna um erro, dizendo que "um número erado de argumentos foi especificado para a função."
    Nosso código tem algumas customizações e talvez tenha relação com este erro.
    veja abaixo como ficou após eu inserir o parâmetro recomendado:

        // <GBR>
        if (BrazilParameters::isEnabled())
        {
            TaxNumValidate_BR::postingSalesLegalTxt(salestable.Salesid);
            //transitDeposit = salesOperationType.DlvTransitDeposit;
    
            //<I9>
            //<SRL_C089_ThirdInventory>
            //Caso o nome do estoque possua "%1" substitui pelo Id do site
            if(String::contains(salesOperationType.DlvTransitDeposit, "%"))
            {
                 transitDeposit = strFmt(salesOperationType.DlvTransitDeposit,salestable.InventSiteId);
            }
            else
            {
            //</SRL_C089_ThirdInventory>
            //</I9>
                 transitDeposit = salesOperationType.DlvTransitDeposit;
            }//</SRL_C089_ThirdInventory></I9>
    
    
    
    
            if (transitDeposit != "")
            {
                transitItemJournal = new DlvTransitInventControl_BR(custInvoiceJour.InvoiceId);
            }
        }

    Muito obrigado pela ajuda !

    Abraços.

    terça-feira, 3 de dezembro de 2013 16:13
  • Verdade...esqueci do parâmetro "no outro lado"...

    Me adiciona no skype: thejxt@hotmail.com

    Josemar

    terça-feira, 3 de dezembro de 2013 16:35
  • Sem palavras para agradecer o Josemar !
    Ficou excelente !
    Muito obrigado mesmo !!!!
    Abraços.
    terça-feira, 3 de dezembro de 2013 18:53
  • Apenas complementando informações caso alguém mais procure e ache essa thread, o KB2852338 lançado em Maio/2013 corrigiu isso. Acontece em clientes que tem textos legais do tipo Memo atribuídos nas linhas (acontece quando são textos de CFOP).

    quinta-feira, 20 de março de 2014 21:47
  • Boa noite meu caro,,,

    Notei que a solução atendeu de forma perfeita, poderia compartilhar comigo também?

    Não entendi corretamente o "outro parâmetro" que vc citou,,,

    Desde já agradeço

    quarta-feira, 26 de março de 2014 20:47
  • Olá Arildo !

    A alteração na classe SalesFormLetter_Invoice, no método UpdateNow, você deve procurar a linha que tem este comando:

    TaxNumValidate_BR::postingSalesLegalTxt(); 

    e substituir por:

    TaxNumValidate_BR::postingSalesLegalTxt(salestable.SalesId); 

    Eu inseri 
    salestable.SalesId, que tornou a busca/retorno mais rápido.

    Hoje trabalhamos mais melhorias, como correção de índices e etc, pois temos alguns picos de lentidão, mas, ao alterar esta classe, tivemos um ótimo ganho de desempenho.

    Abraços

    quarta-feira, 26 de março de 2014 20:56
  • Mais uma vez agradeço Josemar,   porem como sou iniciante nas tentativas com essas alterações

    elas não sendo efetivadas,, creio que não possuo licença de desenvolvimento, caso eu esteja errado

    sinta-se a vontade para comentar,,  realizei a alteração em minha Base de Testes, compilei e salvei,

    porem ao fechar o AX, não efetivou a alteração...

    Sds

    quinta-feira, 27 de março de 2014 15:44
  • Arildo,

    você deve realizar a alteração, salvar e exportar a classe.

    Depois, basta importar esta mesma classe, substituindo-a. Assim ela efetivará a alteração.

    quinta-feira, 27 de março de 2014 15:51
  • Bom dia Arildo,

    Você conseguiu realizar a alteração da classe SalesFormLetter_Invoice?

    Caso tenha conseguido, altere também a classe TaxNumValidate_BR, método postingSalesLegalTxt

    Altere o select do "custSalesLegalTxtLoc" e "custSalesLineLegalTxtLoc" colocando o código abaixo:

     while select forupdate custSalesLegalTxtLoc
        where (custSalesLegalTxtLoc.SalesId == _salesid || !_salesid
        join salesLegalTxtSetupLoc where custSalesLegalTxtLoc.SalesLegalTxtId == salesLegalTxtSetupLoc.SalesLegalTxtId &&
            salesLegalTxtSetupLoc.SalesLegalTxtSection == LegalTxtSection_BR::Lines
        {
            custSalesLegalTxtLoc.delete();
        }

        ttscommit;

        ttsbegin;
        while select forupdate custSalesLineLegalTxtLoc
        where (custSalesLineLegalTxtLoc.SalesId == _salesid || !_salesid
        join salesLegalTxtSetupLoc where custSalesLineLegalTxtLoc.SalesLegalTxtId == salesLegalTxtSetupLoc.SalesLegalTxtId &&
        salesLegalTxtSetupLoc.SalesLegalTxtSection == LegalTxtSection_BR::Memo
        {
            if(CFOPTable_BR::findCfopId_SalesPurch((SalesLine::find(custSalesLineLegalTxtLoc.SalesId,
                custSalesLineLegalTxtLoc.LineNum).CustCFOPId),(SalesLine::find(custSalesLineLegalTxtLoc.SalesId,
                custSalesLineLegalTxtLoc.LineNum).SalesPurch)).InvoiceTxtId != custSalesLineLegalTxtLoc.SalesLegalTxtId)
            {
                custSalesLineLegalTxtLoc.delete();
            }
        }

    Tente realizar a alteração e nos dê um feedback. Se precisar me encaminha um email no thejxt@hotmail.com.

    Abraço!

    • Sugerido como Resposta Josemar Xavier segunda-feira, 31 de março de 2014 13:41
    segunda-feira, 31 de março de 2014 13:41