Lentidão em gravar arquivo

[JoséQuintas]

Descobri qual é o problema de estar gravando o backup de forma lenta.

O problema é..... ANTIVÍRUS

Até aí... já seria problema...
Mas tem um problema maior: ANTIVÍRUS DEFAULT DO WINDOWS 10 !!!!!

Adicionando a pasta de arquivos como exceção, mais rápido.

Tá parecendo os programas de segurança de banco !!!

Quase 10 minutos pra gravar CADA ano de XML, e liberando a pasta no antivírus, cerca de 26 segundos.

Isso vai complicar....

[Itamar M. Lins Jr.]

Ola!
Eu disse que servidor que se preze de BD não tem antivírus!
Não tem nenhum navegador, só mesmo o BD, MySQL, MariDb, etc mais nada. Todas as portas TCP/UDP fechadas só a do BD aberta.
Nenhuma interface gráfica. Somente o SGBD lá fazendo e retornando as consultas.
Nesta época que estudava isso, usa o Linux com Reiser/FS, era e ainda é muito bom com gravação do arquivos rápido, puxava a tomada do interruptor e não perdia os dados. Pena que o cara que criou o ReiserFS, assassinou a esposa! Que triste isso, o cara tá preso.
https://pt.wikipedia.org/wiki/ReiserFS

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Ola!
Eu disse que servidor que se preze de BD não tem antivírus!

Só deixou passar um grande detalhe:
Quem falou de servidor?
É a gravação em disco mesmo.

[asimoes]

Esse processo de gravação não pode ser feito no servidor e executado nele?

[JoséQuintas]

Esse processo de gravação não pode ser feito no servidor e executado nele?

NÃO QUERO FAZER ISSO.

Só pra curiosidade, mas NÃO tem a ver com o problema:

Vários backups do MySQL, e nem dá tempo do servidor registrar o processo.
Mas aqui ok, está desativado o antivírus pras pastas de aplicativo, nesta situação é normal demorar pra gravar em disco.

Se no backup é assim, e obrigatoriamente está sempre copiando (por partes), imaginem no uso normal.
É só pra mostrar como SQL é PHODA !!!
Muitos backups copiando do servidor, e a rede e o servidor ainda conseguem ficar livres !!!

[JoséQuintas]

Mesmo assim....
Menos de 2 milhões de registros, e a previsão é 15 minutos...
Isso só dessa tabela, fora as demais.

[JoséQuintas]

Tinha usado hb_NTOS() pra ver se ficava mais rápido.... mas não dá, o Harbour é ruim pra tratar decimais.
Tem horas que o hb_Ntos() retorna 1.00000 quando deveria ser 1
Retornei minha função de converter número, que funciona melhor.

[JoséQuintas]

Tudo bem, nesse cliente o backup roda depois da meia noite, automático.
Mas como estou testando conversão de versão, e NÃO retiro o backup mesmo do teste, tenho que esperar o backup.
20 minutos desde o post anterior, e ainda testando kkkk
Só dá pra saber se passou, depois que terminar o backup.
Não tenho certeza se ainda é o mesmo backup anterior, ou se já comecei outro depois de um erro.


Com certeza é um segundo backup, só não sei se quando postei fazia parte do primeiro ou deste segundo.

[JoséQuintas]

Erro executando comando:-2147217900 [ma-3.1.6][5.7.12-log]Invalid default value for 'PDPEDREL'

CREATE TABLE IF NOT EXISTS JPPEDIDO ( ... PDPEDREL Int(11) NOT NULL DEFAULT ''

a diferença que mencionei do MariaDB.
é um campo numérico tendo como default espaço em branco... aí não dá.... rs
Mas o MariaDB só dá erro se for criar tabela, já o MySQL confere o comando mesmo que não crie a tabela.

É só comentário extra... mas vai começar o backup tudo de novo kkkk
Obrigatoriamente, meu aplicativo faz backup antes da conversão, mesmo que seja só teste na minha máquina.
E enquanto não completar a conversão, cria backup a cada tentativa de carregar o aplicativo.

[JoséQuintas]

Pra restaurar a diferença é brutal.

meia hora pra criar o arquivo, e alguns minutos pra restaurar.
O problema está no processamento local de backup/gravação em disco LOCAL.

[bencz]

José, sobre a conversão numerica...
Veja este simples programa que fiz para você ter uma ideia...

Código: Selecionar todos

function start()
    local nTest1 := 1.45668
    local nTest2 := 2
    local nTest3 := 3.45
    local nTest4 := 0.444
    local nTest5 := nil
    
    ? ALLTRIM(CSTR(nTest1)) + " -----> " + ALLTRIM(CSTR(CAST_TO_INT(nTest1)))
    ? ALLTRIM(CSTR(nTest2)) + " -----> " + ALLTRIM(CSTR(CAST_TO_INT(nTest2)))
    ? ALLTRIM(CSTR(nTest3)) + " -----> " + ALLTRIM(CSTR(CAST_TO_INT(nTest3)))
    ? ALLTRIM(CSTR(nTest4)) + " -----> " + ALLTRIM(CSTR(CAST_TO_INT(nTest4)))
    ? ALLTRIM(CSTR(nTest5)) + " -----> " + ALLTRIM(CSTR(CAST_TO_INT(nTest5)))
return nil

#pragma BEGINDUMP

#include "hbapi.h"   

HB_FUNC( CAST_TO_INT )
{
    int val = hb_parni(1);
    hb_retni(val); 
}

#pragma ENDDUMP

O resultado do programa é:

Código: Selecionar todos

1.45668 -----> 1
2 -----> 2
3.45 -----> 3
0.444 -----> 0
NIL -----> 0

[JoséQuintas]

Acontece que nem sempre o número é inteiro.
TODAS as funções do Harbour falham pra essa conversão, inclusive hb_NTOS()
Tem número sem decimais e número com decimais.
NÃO quero fazer um campo por vez individualmente.

Vai ficar como está até o término da migração.

[bencz]

Humm....
Desconfio que o problema não seja no harbour... e sim, na propria CPU!!!
Isso se chama erro da mantissa do padrão IEEE 754, que é o padrão de números de ponto flutuantes utilizados pelas CPUs...

Quer um exemplo desse erro..., execute o seguinte código:

Código: Selecionar todos

function start()
    local nX := 0.1
    
    while nX != 1.0
        ? cstr(nX)
        nX += 0.1
    end
return nil

você vai ver que o código entra em um loop infinto, pois como o computador utiliza notação binário e como o decimal 0.1 em binário corresponde a um binário periódico (como a dízima periódica resultante do 1/3 que é 0.3...)
Então, possivelmente as funções que você está falando que não retornam o valor correto, estejam retornando o valor correto no "Ponto de vista" das funções, pois elas estão identificando que o numero é um numero de ponto flutuante, mas, a formatação para string não traz esse numero que está causando essa identificação, que possivelmente esteja la entre as ultimas casas possíveis do numero...

Uma alternativa, seria converter para string o valor e fazer uma "analise" do resultado da conversão... algo tipo...

Código: Selecionar todos

function start()
    ? formataNumero(1.000000000000000001)
    ? formataNumero(2.000045000000000001)
    ? formataNumero(3)
    ? formataNumero(4.00045)


    inkey(20)
return nil

function formataNumero(nNumero)
    local cResult := ''
    local aNumero := {}
    local cNumero := CSTR(nNumero)
    
    aNumero := HB_ATokens(cNumero, '.')
    if len(aNumero) >= 2
        if len(strtran(aNumero[2], '0', '')) == 0
            cResult := aNumero[1]
        else
            cResult := cNumero
        endif
    else
        cResult := aNumero[1]
    endif   
    
return cResult

[bencz]

E relembrando... veja essa explicação que dei neste tópico: viewtopic.php?f=4&t=14869&p=87150
Eu deixei bem detalhado sobre este problema da mantissa