Claudio, Obrigado pelas sugestões.

Se possível, encontra em anexo duas consultas, uma do mês 12/2013 e outra
01/2014 e a estrutura da tabela. O que acontece é o seguinte, eu importo os
produtos de uma determinada empresa todos os meses. Ex. Trabalhei no mês
12/2013 e quando vou começar no mês 01/2014 o sistema pergunta se eu quero
importar os produtos do mês anterior e eu clico em sim e o sistema importa
os produtos para o mês 01/2014, porem quando gero um relatório comparando
os meses, um relatório tem 396 pg e outro 391 pg, são 5 paginas com 30
produtos cada, que são 150 produtos que sumiram do nada no sistema, a
formatação do texto do relatório é a mesma... Muito estranho.

Eu estou aqui pedindo ajuda, pois não tenho tanto conhecimento em postgres
e o pessoal do suporte do sistema não ajuda em nada!..

Obrigado.


Em 10 de fevereiro de 2014 09:21, Claudio Bezerra Leopoldino <
claudiob...@yahoo.com.br> escreveu:

> As hipóteses para o seu problema, são:
>
> 1- Migração de dados do Nexus para o postgresql trouxe dados duplicados ou
> errados. Creio que não se aplica neste caso, pois depois de um anos já
> teria sido descoberto;
> 2- Os dados que estão sendo inseridos, alterados e excluídos estão
> incorretos. Rever as rotinas de modificação de dados no banco;
> 3- As consultas realizadas não estão utilizando os filtros e junções
> corretos. Auditar consultas;
> 4- As consultas realizadas estão utilizando níveis de isolamento muito
> flexíveis. Rever as configurações para "Transact isolation levels".
>
> Creio que as hipóteses 2, 3 e 4 são as mais prováveis.
>
> O vacuum vai ter dar melhor aproveitamento do espaço de armazenamento e
> maior rapidez nos acessos aos dados, mas não vai melhorar a consistência
> da sua base de dados.
>
> Cordialmente,
>
> Cláudio Leopoldino
> postgresqlbr.blogspot.com/
> =================================================
>
>
>   Em Segunda-feira, 10 de Fevereiro de 2014 7:53, "Guimarães Faria
> Corcete DUTRA, Leandro" <l...@dutras.org> escreveu:
>   2014-02-10 Thiago Haroldo <thi...@sedcontabilidade.com.br>:
> >
> > Não, eu não deixei ele ligado, pois queria saber mais informações sobre o
> > mesmo.
>
> Não altere as configurações padrão sem ter idéia do que está fazendo.
> Um ano sem limpeza da base (é isso que a 'aspiração' [/vaccuum/] faz)
> é temerário.
>
>
> > Qual a versão do PostgreSQL que está usando?
> >
> > Estou usando a Versão 9.0
>
> Alguma razão para uma base que tem apenas um ano usar uma versão tão
> antiga?  Pelo menos atualize imediatamente para a última 9.0.X, que é
> a 9.0.15, porque isso é essencial e geralmente só exige a leitura das
> notas de versão (/release notes/), e já vá planejando atualizar para a
> 9.3 ou, idealmente, a futura 9.4, porque a 9.0.X deixará de ser
> suportada ano que vem e a gente nunca sabe as intercorrências que
> podem atrasar uma atualização.
>
>
> > Porem estou achando estranho é que algumas vezes geramos relatórios no
> > sistema e ele traz  algumas informações erradas...
>
> Então o que precisas é nos trazer, pelo menos, um exemplo de consulta,
> estrutura das relações (tabelas) consultadas, dados de origem e
> resultados obtidos e esperados.  Isso nada tem a ver com manutenção da
> base, a princípio.
>
>
> > Achei que poderia ser
> > sujeira na base de dados... Rodando o Vaccum resolveria nossos
> problemas...
>
> Não, a limpeza não altera resultados.  A menos que tua base esteja tão
> podre que os dados estejam inconsistentes, mas aí daria tanto problema
> que já nos terias procurado há meses.
>
>
>
> > Obs: Não sou DBA, mas tenho que me virar, pois a empresa onde trabalho
> não é
> > de grande porte e não tem um profissional destinado a este serviço.
>
> Por isso mesmo tinhas de nos ter procurando antes de desligar algo tão
> essencial quanto a limpeza automática da base.
>
>
> --
> skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191              gTalk: xmpp:leand...@jabber.org
> +55 (11) 9406 7191        ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>


-- 
Thiago Haroldo Barreto
Assistente de TI
Sed Contabilidade S/S Ltda
(34) - 3662-1124
thi...@sedcontabilidade.com.br <clau...@sedcontabilidade.com.br>







*Lembre-se de que ao evitar o desperdício, além de economizar dinheiro com
papel e tinta, você também ajuda o nosso planeta. Bom para seu bolso,
melhor para o mundo!*
-- Table: wfiscal.cd00800

-- DROP TABLE wfiscal.cd00800;

CREATE TABLE wfiscal.cd00800
(
  idcodigo character varying(40) NOT NULL,
  dtinicial timestamp without time zone,
  dtfinal timestamp without time zone,
  cdcodigo integer,
  cdclassificacao character varying(20),
  nmdescricao character varying(53),
  nmunidade character varying(6),
  codespecifico character varying(60),
  codsittrib integer,
  aliqipi double precision,
  aliqicms double precision,
  redbase double precision,
  basest double precision,
  cdespecie integer,
  cdunmedida integer,
  fatorconv integer,
  tpproduto character varying(1),
  dsproduto character varying(6),
  codean character varying(14),
  codrelevante character varying(7),
  cdproduto integer,
  descunidade character varying(30),
  iditemgenero character varying(10),
  stimune character varying(1),
  stcombustivelsolvente character varying(1),
  cdprodsefaz character varying(4),
  cdanp integer,
  nrtipoitem integer,
  cdgeneroitem integer,
  cdipi integer,
  cdpis integer,
  cdcofins integer,
  stcontroleipi character varying(1),
  codanterior character varying(14),
  codespecificoant character varying(60),
  datacodanterior timestamp without time zone,
  cdpisent integer,
  cdcofinsent integer,
  aliqdifpis double precision,
  aliqdifcofins double precision,
  incidemp540 boolean,
  codigo_atividade_id smallint,
  cnpj_cpf_terceiros bigint,
  codigo_importacao character varying(60),
  cdipient smallint,
  tipo_origem_registro smallint,
  data_importacao date,
  nome_usuario_importacao character varying(20),
  data_alteracao date,
  nome_usuario_alteracao character varying(20),
  regime_unidade_medida_id integer,
  regime_unidade_medida_grupo smallint,
  regime_unidade_medida_marca_id smallint,
  producao_propria boolean,
  codigo_tributacao_dia_am character varying(4),
  codigo_geral_dia_am integer,
  gera_matriz_nacional_dia_am boolean,
  natureza_receita_cst04 integer,
  natureza_receita_cst05 integer,
  natureza_receita_cst06 integer,
  natureza_receita_cst07 integer,
  natureza_receita_cst08 integer,
  natureza_receita_cst09 integer,
  CONSTRAINT cd00800_idxprimario PRIMARY KEY (idcodigo)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE wfiscal.cd00800 OWNER TO "ALTERDATA_GROUP_ALTERDATA";

-- Index: wfiscal.cd00800_idx_importacao

-- DROP INDEX wfiscal.cd00800_idx_importacao;

CREATE INDEX cd00800_idx_importacao
  ON wfiscal.cd00800
  USING btree
  (cnpj_cpf_terceiros, codigo_importacao);

-- Index: wfiscal.cd00800_idxcodean

-- DROP INDEX wfiscal.cd00800_idxcodean;

CREATE INDEX cd00800_idxcodean
  ON wfiscal.cd00800
  USING btree
  (dtinicial, dtfinal, codean);

-- Index: wfiscal.cd00800_idxcodespecifico

-- DROP INDEX wfiscal.cd00800_idxcodespecifico;

CREATE INDEX cd00800_idxcodespecifico
  ON wfiscal.cd00800
  USING btree
  (dtinicial, dtfinal, codespecifico);

-- Index: wfiscal.cd00800_idxcodigo

-- DROP INDEX wfiscal.cd00800_idxcodigo;

CREATE INDEX cd00800_idxcodigo
  ON wfiscal.cd00800
  USING btree
  (dtinicial, dtfinal, cdcodigo, cdclassificacao, codespecifico);

-- Index: wfiscal.cd00800_idxdata

-- DROP INDEX wfiscal.cd00800_idxdata;

CREATE INDEX cd00800_idxdata
  ON wfiscal.cd00800
  USING btree
  (dtinicial, dtfinal);

-- Index: wfiscal.cd00800_idxncm

-- DROP INDEX wfiscal.cd00800_idxncm;

CREATE INDEX cd00800_idxncm
  ON wfiscal.cd00800
  USING btree
  (dtinicial, dtfinal, cdclassificacao);

Attachment: consulta 01 de 2014.log
Description: Binary data

Attachment: consulta 12 de 2013.log
Description: Binary data

_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a