[oracle_br] funcionamento do segmento de LOB
Bom dia! Estou com dúvida quanto ao funcionamento de segmento de LOB, na questão de utilização de espaço no banco de dados. Se eu consulto o tamanho da minha tabela diariamente, eu tenho crescimento de 20MB/dia, já se consulto o segmento de LOB, o crescimento é de 300MB/dia. Contando que tenho 3 tabelas com esse tipo de informação, então estou tendo um crescimento diário por volta de 1.3GB. Eu quero entender, o porque o segmento de LOB tem essa discrepância? Se tem algo que eu possa fazer para diminuir esse crescimento? O Chiappa, passou algumas informações sobre o CLOB alguns meses atrás, me ajudo bastante, vou procurar a thread para novas informações. Se puderam indicar algum material ou explicação, para o entendimento do segmento, ficarei grato. Márcio.
Re: [oracle_br] funcionamento do segmento de LOB
Márcio, Toda coluna do tipo LOB (Exs.: CLOB e BLOB) tem seu próprio segmento (isolado da tabela), que nada mais é do que a estrutura lógica de armazenamento de objetos que possuam dados, tais como tabelas e visões materializadas. LOB é a sigla de Large Object, então o próprio nome sugere que colunas desse tipo armazenam objetos grandes, logo , se vc realmente armazenar objetos grandes nestas colunas (como por exemplo imagens ou vídeos em BLOB), é normal que o segmento destas colunas sejam maiores do que o segmento das tabelas. Segue abaixo o link de um artigo em meu blog onde vc encontrará mais informações sobre LOB: http://www.fabioprado.net/2011/09/gerenciando-o-armazenamentodesempenho.html []s Fábio Prado Em 3 de abril de 2014 10:20, Grupos marcio_...@yahoo.com.br escreveu: Bom dia! Estou com dúvida quanto ao funcionamento de segmento de LOB, na questão de utilização de espaço no banco de dados. Se eu consulto o tamanho da minha tabela diariamente, eu tenho crescimento de 20MB/dia, já se consulto o segmento de LOB, o crescimento é de 300MB/dia. Contando que tenho 3 tabelas com esse tipo de informação, então estou tendo um crescimento diário por volta de 1.3GB. Eu quero entender, o porque o segmento de LOB tem essa discrepância? Se tem algo que eu possa fazer para diminuir esse crescimento? O Chiappa, passou algumas informações sobre o CLOB alguns meses atrás, me ajudo bastante, vou procurar a thread para novas informações. Se puderam indicar algum material ou explicação, para o entendimento do segmento, ficarei grato. Márcio. -- *Fábio Prado* http://www.fabioprado.net/2014/01/oracle-ace-o-que-e-isso.html www.fabioprado.net Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle
RES: [oracle_br] funcionamento do segmento de LOB
Fábio, bacana o seu artigo. A rotina de shrink eu costumo fazer a cada trimestre nessas tabelas, mas não tenho muito ganho, pois as tabelas sofrem mais inserts e as alterações que ela sofre são em outros campos, não no campo CLOB. Ah! Na criação da tabela, eu já havia colocado o CLOB em tablespace separado, então hoje se este meu banco de dados tem 600GB, tenho 300GB somente de CLOB, é um banco de nota fiscal eletrônica e os campos contém o XML que é enviado para Sefaz. Eu entendo que é um comportamento do tipo do campo(CLOB) ter esse crescimento, aliás estou colocando um XML nele, que posso ter um XML com vários itens ou um XML com apenas 1 item. Levantei essa thread no grupo, pois a minha gerência entende que não pode crescer dessa maneira, eu já expliquei a forma como está estruturada as tabelas e como o Oracle trabalha, e queria outra opinião para confrontar com a minha, se eu não deixei escapar nada ou se tem algo que eu não saiba e possa nos ajudar. Não conhecia a dica do CACHE, vou tentar colocar no meu ambiente de homologação. Grato. De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Fabio Prado Enviada em: quinta-feira, 3 de abril de 2014 10:49 Para: oracle_br@yahoogrupos.com.br Assunto: Re: [oracle_br] funcionamento do segmento de LOB Márcio, Toda coluna do tipo LOB (Exs.: CLOB e BLOB) tem seu próprio segmento (isolado da tabela), que nada mais é do que a estrutura lógica de armazenamento de objetos que possuam dados, tais como tabelas e visões materializadas. LOB é a sigla de Large Object, então o próprio nome sugere que colunas desse tipo armazenam objetos grandes, logo , se vc realmente armazenar objetos grandes nestas colunas (como por exemplo imagens ou vídeos em BLOB), é normal que o segmento destas colunas sejam maiores do que o segmento das tabelas. Segue abaixo o link de um artigo em meu blog onde vc encontrará mais informações sobre LOB: http://www.fabioprado.net/2011/09/gerenciando-o-armazenamentodesempenho.html []s Fábio Prado Em 3 de abril de 2014 10:20, Grupos marcio_...@yahoo.com.br escreveu: Bom dia! Estou com dúvida quanto ao funcionamento de segmento de LOB, na questão de utilização de espaço no banco de dados. Se eu consulto o tamanho da minha tabela diariamente, eu tenho crescimento de 20MB/dia, já se consulto o segmento de LOB, o crescimento é de 300MB/dia. Contando que tenho 3 tabelas com esse tipo de informação, então estou tendo um crescimento diário por volta de 1.3GB. Eu quero entender, o porque o segmento de LOB tem essa discrepância? Se tem algo que eu possa fazer para diminuir esse crescimento? O Chiappa, passou algumas informações sobre o CLOB alguns meses atrás, me ajudo bastante, vou procurar a thread para novas informações. Se puderam indicar algum material ou explicação, para o entendimento do segmento, ficarei grato. Márcio. -- Fábio Prado http://www.fabioprado.net/2014/01/oracle-ace-o-que-e-isso.html www.fabioprado.net http://www.fabioprado.net/ Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle
Re: [oracle_br] funcionamento do segmento de LOB
Se o armazenamento for um ponto crítico p/ vc e vc estiver usando Oracle 11GR2 ou superior, avalie o uso de SecureFiles Lobs ( http://docs.oracle.com/cd/E11882_01/appdev.112/e18294/adlob_smart.htm) utilizando compressão e deduplicação (que poderá depender de licenciamento da Option Advanced Compression). []s Em 3 de abril de 2014 11:09, Grupos marcio_...@yahoo.com.br escreveu: Fábio, bacana o seu artigo. A rotina de shrink eu costumo fazer a cada trimestre nessas tabelas, mas não tenho muito ganho, pois as tabelas sofrem mais inserts e as alterações que ela sofre são em outros campos, não no campo CLOB. Ah! Na criação da tabela, eu já havia colocado o CLOB em tablespace separado, então hoje se este meu banco de dados tem 600GB, tenho 300GB somente de CLOB, é um banco de nota fiscal eletrônica e os campos contém o XML que é enviado para Sefaz. Eu entendo que é um comportamento do tipo do campo(CLOB) ter esse crescimento, aliás estou colocando um XML nele, que posso ter um XML com vários itens ou um XML com apenas 1 item. Levantei essa thread no grupo, pois a minha gerência entende que não pode crescer dessa maneira, eu já expliquei a forma como está estruturada as tabelas e como o Oracle trabalha, e queria outra opinião para confrontar com a minha, se eu não deixei escapar nada ou se tem algo que eu não saiba e possa nos ajudar. Não conhecia a dica do CACHE, vou tentar colocar no meu ambiente de homologação. Grato. *De:* oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] *Em nome de *Fabio Prado *Enviada em:* quinta-feira, 3 de abril de 2014 10:49 *Para:* oracle_br@yahoogrupos.com.br *Assunto:* Re: [oracle_br] funcionamento do segmento de LOB Márcio, Toda coluna do tipo LOB (Exs.: CLOB e BLOB) tem seu próprio segmento (isolado da tabela), que nada mais é do que a estrutura lógica de armazenamento de objetos que possuam dados, tais como tabelas e visões materializadas. LOB é a sigla de Large Object, então o próprio nome sugere que colunas desse tipo armazenam objetos grandes, logo , se vc realmente armazenar objetos grandes nestas colunas (como por exemplo imagens ou vídeos em BLOB), é normal que o segmento destas colunas sejam maiores do que o segmento das tabelas. Segue abaixo o link de um artigo em meu blog onde vc encontrará mais informações sobre LOB: http://www.fabioprado.net/2011/09/gerenciando-o-armazenamentodesempenho.html []s Fábio Prado Em 3 de abril de 2014 10:20, Grupos marcio_...@yahoo.com.br escreveu: Bom dia! Estou com dúvida quanto ao funcionamento de segmento de LOB, na questão de utilização de espaço no banco de dados. Se eu consulto o tamanho da minha tabela diariamente, eu tenho crescimento de 20MB/dia, já se consulto o segmento de LOB, o crescimento é de 300MB/dia. Contando que tenho 3 tabelas com esse tipo de informação, então estou tendo um crescimento diário por volta de 1.3GB. Eu quero entender, o porque o segmento de LOB tem essa discrepância? Se tem algo que eu possa fazer para diminuir esse crescimento? O Chiappa, passou algumas informações sobre o CLOB alguns meses atrás, me ajudo bastante, vou procurar a thread para novas informações. Se puderam indicar algum material ou explicação, para o entendimento do segmento, ficarei grato. Márcio. -- *Fábio Prado* http://www.fabioprado.net/2014/01/oracle-ace-o-que-e-isso.html www.fabioprado.net Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle -- *Fábio Prado* http://www.fabioprado.net/2014/01/oracle-ace-o-que-e-isso.html www.fabioprado.net Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle
Re: RES: [oracle_br] funcionamento do segmento de LOB
Colega, vamos tentar te dar alguns elementos mais : 1. pra variar vc Não Diz se está usando 11g ou não, e se for 11g se está usando SECURE FILES ou não : o fato porém é que além da questão da possibilidade de compactação, SECURE FILES são uma opção mais refinada/moderna de controle de espaço - entre outras coisas, não precisam de PCTVERSION declarado no LOB para controlar versionamento/percentual de reuso, por exemplo Então considere SERIAMENTE a possibilidade de os usar se vc tá na versão 11g 2. é Evidente que um CLOB pode possuir *** muito mais ** dados, muito mais caracteres do que todo o resto do seu registro lógico (composto por escalares de pequeno tamanho, como DATE, NUMBER e VARCHAR2), então Totalmente Não faz sentido a comparação que vc faz , tipo ah, tenho 300 GB de CLOB contra um número muito menor de espaço ocupado por outros dados : o que vc tem que analisar é a QUANTIDADE DE CARACTERES armazenados versus esses 300 GB, okdoc ?? Digamos que vc tem no total duzentos e muitos GBs de informação gravados nesses LOBs, aí ocupar 300 GB em disco é Totalmente o esperado, sim ?/ Sempre há algum overhead... A questão é que no RDBMS Oracle, por questão de performance, ele NUNCA aloca/grava/usa o espaço em disco byte-a-byte : ele sempre lê/usa/grava uma quantidade fixa de kbytes cahamado BLOCO, e ao pedir espaço em disco pro SO ** nunca ** pede um bloco por vez, mas sim uma quantidade de blocos sequencias/juntinhos, o chamado EXTENT... Assim, mesmo que vc for gravar uma linha que seja de informação, ao menos um extent já terá sido alocado, yep ?? E na hora de gravar a informação em cada bloco dentro de cada extent, o comportamento normal é mesmo deixar um pouco de espaço reservado para futuros UPDATEs... E ** NUNCA ** esqueça, necessariamente o LOB não armazena Só e Apenas o dado : vc vai ter também que manter um segmento de LOB INDEX, vc vai ter estruturas de controle Então NUNCA gravar x bytes no LOB significa que vc gastou x bytes em discos, é x bytes + o overhead... Para comparar dados x espaço gasto (se vc não já tiver essa informação) vc pode fazer algo tipo : select sum(dbms_lob.getlength(colunalob)) from tabelaquecontémolob; e comparar contra um SELECT sum(bytes) from DBA_EXTENTS WHERE tablespace_name = nomedatablespacequesócontémLOBsque vc diz que tem == Então, ** SE ** vc já pediu um SHRINK da coluna CLOB (*** Não É *** shrink da tabela, é DA COLUNA CLOB!!) e não teve grande alteração, eu Suponho que a qunatidade de dados deve ser muito grande, justificando os 300 GB Se vc ainda julgar o overhead grande, vc até PODE diminuir isso alterando o porcentual de espaço reservado, o CHUNKSIZE, etc : e como isso não funciona para o passado (o que já está alocado, está alocado), vc pode considerar,depois de ter alterado os parâmetros em questão, criar uma NOVA tablespace (sempre LMT e AutoAllocate, já que vc não sabe o tamanho que o dado LOB terá) e mover os lob segments/lobindexes para ela... 3. Ainda por questão de performance, quando vc deleta os dados (sejam em LOBs ou não) o comportamento do RDBMS é ** deixar ** esse espaço ainda alocado para o mesmo segmento que os usou, pois ele pensa que os segmentos são dinãmicos, que brevemente o mesmo segmento que sofreu a deleção VAI sofrer novos INSERTs, e aí esse espaço VAi ser reusado, e o fato dele já estar pré-alocado acelerará EM MUITO essa entrada de dados, sim E isso nem é FRAGMENTAÇÂO propriamente dita, pois esse espaço em branco, REPITO, vai SIM ser reutilizado nos próximos INSERTs, ele Absolutamente não está perdido, não é impossível de ser usado, como ocorre na fragmentação REAL, okdoc ?? O shrink de lob e a movimentação (principalmente esta última) vão ser efetivos também neste caso de reuso de espaço deletado, se for o caso : leia http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:7246820117571 (é uma thread longa mas Absolutamente informativa e importante), http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3084920323218 , http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3998444100346949788 e http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3679447698936 para refs e exemplos... []s Chiappa
Re: RES: [oracle_br] funcionamento do segmento de LOB
Um exemplo para mostrar em ação o overhead do LOB (que, COMO EU DISSE, em
muitos casos pode ser Sensivelmente Diminuído alterando-se os params de
controle de alocação E usando sercurefiles, mas SEMPRE vai existir) :
- crio a tablespace LMT autoallocate :
SYSTEM:@xe:SQLcreate tablespace TS_LOB datafile
'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\TS_LOB_01.DBF' size 1G extent management
local autoallocate;
Tablespace criado.
= crio a tabela que contém um LOB (CLOB no caso) , desabilitando storage in
row (para que a alocação só ocorra na tablespace dedicada a LOBs ainda que os
dados a inserir sejam pequenos : não é uma boa idéia sempre, mas para fins
didáticos/de exibição vamos fazer assim) :
SYSTEM:@xe:SQLcreate table T_LOB (c1 number, c2 varchar2(4000), c3 clob)
2 lob (C3) STORE AS ( TABLESPACE TS_LOB DISABLE STORAGE IN ROW NOCACHE
CHUNK 8192);
Tabela criada.
= insiro uma linha só :
SYSTEM:@xe:SQLinsert into T_LOB values (1, 'Linha 1', 'primeira linha inserida
no CLOB');
1 linha criada.
SYSTEM:@xe:SQLcommit;
Commit concluÝdo.
= veja que já alocou um EXTENT inteiro para cada tipo de segmento que um LOB
exige, como eu disse antes :
SYSTEM:@xe:SQLselect segment_name, segment_type, extent_id, bytes, blocks from
dba_extents where tablespace_name='TS_LOB';
SEGMENT_NAMESEGMENT_TYPEEXTENT_ID BYTES
BLOCKS
--- -- -- --
--
SYS_LOB020052C3$$ LOBSEGMENT 0 65536
8
SYS_IL020052C3$$LOBINDEX0 65536
8
= vou inserir mais algumas linhas :
SYSTEM:@xe:SQLed
Gravou file afiedt.buf
1 DECLARE
2 l_clob clob := empty_clob();
3 BEGIN
4 FOR i IN 1..10 LOOP
5INSERT INTO T_LOB (c1, c2, c3) VALUES (i+1, 'Linha:'|| to_char(i+1),
empty_clob()) RETURNING c3 INTO l_clob;
6-- create a 400,000 bytes clob
7--FOR i IN 1..100 LOOP
8-- dbms_lob.append(l_clob, rpad ('*',4000,'*'));
9--END LOOP;
10 END LOOP;
11* END;
SYSTEM:@xe:SQL/
Procedimento PL/SQL concluÝdo com sucesso.
SYSTEM:@xe:SQLcommit;
Commit concluÝdo.
== Como os CLObs vazios que inseri couberam , não houveram novas alocações :
SYSTEM:@xe:SQLselect segment_name, segment_type, extent_id, bytes, blocks from
dba_extents where tablespace_name='TS_LOB';
SEGMENT_NAMESEGMENT_TYPEEXTENT_ID BYTES
BLOCKS
--- -- -- --
--
SYS_LOB020052C3$$ LOBSEGMENT 0 65536
8
SYS_IL020052C3$$LOBINDEX0 65536
8
= agora vou inserir novas linhas na tabela Mas com informação nos CLOBs :
SYSTEM:@xe:SQLDECLARE
2 l_clob clob := empty_clob();
3 BEGIN
4 FOR i IN 1..10 LOOP
5INSERT INTO T_LOB (c1, c2, c3) VALUES (i+1, 'Linha:'|| to_char(i+1),
empty_clob()) RETURNING c3 INTO l_clob;
6-- create a 400,000 bytes clob
7FOR i IN 1..100 LOOP
8 dbms_lob.append(l_clob, rpad ('*',4000,'*'));
9END LOOP;
10commit;
11 END LOOP;
12* END;
Procedimento PL/SQL concluÝdo com sucesso.
= veja que cfrme os dados foram crescendo e novo espaço foi necessário, novos
extents foram alocados :
SYSTEM:@xe:SQLselect segment_name, segment_type, extent_id, bytes, blocks from
dba_extents where tablespace_name='TS_LOB';
SEGMENT_NAMESEGMENT_TYPEEXTENT_ID BYTES
BLOCKS
--- -- -- --
--
SYS_LOB020052C3$$ LOBSEGMENT 0 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 1 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 2 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 3 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 4 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 5 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 6 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 7 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 8 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 9 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 10 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 11 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 12 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 13 65536
8
Re: RES: [oracle_br] funcionamento do segmento de LOB
Obs complementar : sobre CACHEs, tenha em mente que eles ABSOLUTAMENTE não fazem sentido SEMPRE e em Qualquer caso : qualquer tipo de CACHE só é efetivo SE (além de vc ter memória SUFICIENTE sobrando pra ele, não tendo que tirar de áreas mais nobres), os dados são lidos Constantemente - óbvio Ululante que se vc subiu os dados lidos para um cache mas depois ninguém mais precisou consultar esses mesmos dados, vc só desperdiçou espaço VERIFIQUE se a sua Aplicação realmente consulta repetidamente esses LOBs, sim ?? Tipicamente LOBs são dados não-estruturados, descrições complementares / detalhes de algo, então não é comum que sejam lidos e relidos constantemente : Até por isso o RDBMS não implementava por default CACHING de LOBs em algumas versões, yep ?? É uma escolha LOCAL, sua, mas BASEADA no que vc conhece do comportamente DA APLICAÇÃO, sim ?? No seu caso só vc sabe dizer, mas NF é o tipo do documento que nromalmente NÂO é consultado frequentemente : o usuário quer saber é o total de vendas no dia, a movimentação de estoque, etc, coisas essas que (ESPERO!!) o teu sistema não te obriga a varrer um LONGO e DESESTRUTURADO LOB para se obter, né não ?? []s Chiappa
[oracle_br] Pergunta rápida sobre options de segurança
Boa noite! Oracle Enterprise Edition Versão 11203 Optando por usar VPD e/ou OSL, teríamos de fazer algum investimento? Ou elas já estão inclusas na EE ? Grato.
Re: [oracle_br] Pergunta rápida sobre options de segurança
Olá Roland Vc pode consultar aqui todas as Features e Options de cada edição do Oracle Database. O que tem pontinho vermelho é feature (ou seja, já incluso). O que tem escrito Option necessita de licenciamento adicional. http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html Em 3 de abril de 2014 18:33, Roland Martins dadim...@yahoo.com.brescreveu: Boa noite! Oracle Enterprise Edition Versão 11203 Optando por usar VPD e/ou OSL, teríamos de fazer algum investimento? Ou elas já estão inclusas na EE ? Grato.
Re: [oracle_br] Pergunta rápida sobre options de segurança
Maravilha Milton! Obrigado! Em Quinta-feira, 3 de Abril de 2014 18:35, Milton Bastos Henriquis Jr. miltonbas...@gmail.com escreveu: Olá Roland Vc pode consultar aqui todas as Features e Options de cada edição do Oracle Database. O que tem pontinho vermelho é feature (ou seja, já incluso). O que tem escrito Option necessita de licenciamento adicional. http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html Em 3 de abril de 2014 18:33, Roland Martins dadim...@yahoo.com.br escreveu: Boa noite! Oracle Enterprise Edition Versão 11203 Optando por usar VPD e/ou OSL, teríamos de fazer algum investimento? Ou elas já estão inclusas na EE ? Grato.
Re: [oracle_br] Pergunta rápida sobre options de se gurança
Roland, Adicionalmente, notar que desconheço a sigla OSL nesse contexto de produto de Segurança : será que vc não quis dizer OSB (Oracle Secure Backup), OLS (Oracle Label Security, provável) ou OAS (Oracle Advanced Security) ?? []s Chiappa
