Menu de navegação

[rwarstatParticipante]

Estou fazendo uma carga entre schemas de um mesmo banco e no schema para o qual devo enviar os dados tenho a tabela movimentos conforme o script abaixo

CREATE TABLE ROOT.MOVIMENTOS
(
REGISTRO INTEGER DEFAULT 0,
EMPRESA INTEGER DEFAULT 0,
TPMOVIM INTEGER DEFAULT 0,
DATA DATE DEFAULT to_date(’01-01-1900′,’dd/mm/yyyy’),
COMPET CHAR(6 BYTE) DEFAULT ”,
CCUSTO CHAR(30 BYTE) DEFAULT ”,
CCDESTINO CHAR(30 BYTE) DEFAULT ”,
PRONT CHAR(30 BYTE) DEFAULT ”,
ATENDE CHAR(30 BYTE) DEFAULT ”,
CODFUNC CHAR(30 BYTE) DEFAULT ”,
CODPROCED CHAR(30 BYTE) DEFAULT ”,
FUNCAO INTEGER DEFAULT 0,
CODITEM CHAR(30 BYTE) DEFAULT ”,
QUANT NUMBER(18,4) DEFAULT 0.0000,
VLRUNIT NUMBER(16,4) DEFAULT NULL,
VLRTOTAL NUMBER(16,4) DEFAULT NULL,
EMBALAGEM CHAR(10 BYTE) DEFAULT ”,
VIDAUTIL NUMBER(18,4) DEFAULT NULL,
DATVIDUTI CHAR(3 BYTE) DEFAULT ”,
DATAIMP DATE DEFAULT to_date(’01-01-1900′,’dd/mm/yyyy’),
IDATIVIDADE INTEGER DEFAULT 0,
IDPROCESSO INTEGER DEFAULT 0,
QUALARQUIV NUMBER(1) DEFAULT 0
)
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING
/

Sei que ela não está devidamente modelada, pois não tem pk, índice, muitos campos char sem necessidade (poderiam ser substituídos por varchar2), mas como não sou o repsonsável não posso mexer. A minha dúvida é se essa estrutura pode influenciar negativamente na performance da carga, já que nessa tabela são inseridas muitas linhas de cada vez. Em um mês foram 52.768 e no outro 59.467, isso em questão de 2hs, que é o tmepo normal de cada carga.

Abraço,
Roberto

[vieriParticipante]

O fato de ela não ter constraints
index e etc.. só irá deixar a carga mais rápida é óbvio….

Mas…
Faça um teste , cria a tabela da maneira que vc deseja
e faça a carga no sqlplus e peça um
SQL>set timing on
SQL>set autot on exp stat

e verifique as stats e tempo de exec.

e compare caso sua tab alterada deixa a carga mais rápida,
documente e envie para o AD/DBA seja lá quem for o responsável!!

[]s
Vieri

[rwarstatParticipante]

Vieri,

Fiz o teste com uma quantidade razoável de dados e não houve diferença. O único impacto é em relação ao tamanho do banco.

Abraço,
Roberto

[Rodrigo AlmeidaParticipante]

Roberto,

Com certeza, a modelagem influência sim e muito nas questões de performance, por alguns motivos simples:

1) Tamanho de Coluna

Na modelagem exposta, o campo INTEGER será equivalente ao NUMBER(38,0) no Oracle, ou seja, o tamanho máximo de armazenamento para a coluna NUMBER, com isso, perda de espaço, alocação de extents desnecessários, possível fragmentação e etc. Resumindo, poderá ter perda de performances.

2) Espaço em disco

Se é tabela de carga, imagina com essa modelagem a quantidade de espaço em disco que será perdido no servidor por má alocação dos extents da tabela.

3) ìndices e PK/Fk

Bom, se for tabela para DW, é bom nem ter índices mesmo, ou PK/FK, pq é um ambiente desnormalizado, se tiver é alguma PK ou FK para dimensão e que deverá ser desabilitada no momento do ETL e posteriormente reconstruída.

E sem dúvida, sem índices e validações (PK/FK), a carga de dados é bem mais rápida.

4) SQL*LOADER

Se quiser fazer carga massiva de dados, utilize o SQL*LOADER (sqlldr) e configure os parâmetros de memória no arquivo ctl para aumentar a performance.

5) Atributos da tabela

A tabela está correta em Permanecer com os parâmetros NOCOMPRESS e NOCACHE, esses podem atrapalhar a performance de carga.

6) PARALLEL

Se quiser aumentar a performance de carga, pense em utilizar o PARALLEL no nível de tabela PARALLEL 4, ou habilite o PARALLEL no nível de sessão, ALTER SESSION ENABLE DML PARALLEL.

Lembre-se, se configurar o PARALLEL em nível de tabela, qualquer outra operação e qualquer usuário irá utilizar o PARALLEL, portanto, o recomendado é sempre durante SOMENTE o processo de carga habilitar o PARALLEL (ALTER TABLE TESTE PARALLEL 4) e no final desabilitar o PARALLEL (ALTER TABLE TESTE PARALLEL 1).

7) MONITORING

Essa opção é para monitoração da utilização de índices na tabela, não é necessário no seu contexto, porém, se existe índices na tabela e querem saber se eles estão sendo utilizados, aí sim habilita o MONITORING, caso contrário, é NOMONITORING.

E esse opção quando habilitada como no seu caso, pode trazer problemas de performance.

Acho que é isso.

Abraços,

[Rodrigo AlmeidaParticipante]

O que mencionei acima é tanto para modelagem e tuning…

[rwarstatParticipante]

Rodrigo,
Quando eu disse que não havia diferença era no quesito de performance para carga. Eu sei e tomo todo o cuidado com os itens que tu relacionou, mas é difícil fazer isso quando não é tu o responsável pela modelagem e quem o é tá pouco se lixando para isso.
E essa é uma das tabelas envolvidas na thread que abri sobre a execução de package no RHEL 4.

Irei tentar convencer o responsável a alterar a modelagem dessa tabela e de outras que tem pelo banco. O que mais tem são campos char(30) ou char(60), tabelas em pk/fk, índices e por aí afora.

Abraço,
Roberto

[Autor]

Posts