Menu de navegação

[leandrolbsParticipante]

Pessoal, em uma de minhas leituras notei scripts para migrar o storage de uma column clob para outra tablespace.


create table teste_lob(
pk_id integer,
campo_lob clob);
--=====
alter table teste_lob move lob(campo_lob) STORE AS (TABLESPACE SYSAUX)

Exemplo!!!!!

Quais melhorias vou ter, caso adote este padrão de campos clob separados em datafiles.

[leandrolbsParticipante]

niguem..rs???

[burgaParticipante]

Acredito que seja mais organizacional mesmo, e também por você poder definir parâmetros de storage diferentes pra tablespace que armazena os CLOBs da tablespace que armazena os outros dados, talvez isso gere um ganho mínimo de desempenho… Mas realmente estou chutando, não sei dizer com certeza. Cadê os mestres??? 😆

[leandrolbsParticipante]

vlw Burga, pelo que venho pesquisando é isso mesmo… mais organização e 2% de desempenho…..

Os mestres, alguma esperiencia?

[josenizParticipante]

Cuidado com a codificação e no modelo de dados.
– Evite SELECT * em qualquer código a ainda mais se houver LOBs, isto áevitara o trafego excessivo entre o servidor e o cliente.
– Por mais que vc selecione alguns campos no SELECT sempre o registro completo é lido do disco para o data buffer cache (caso o mesmo não esteja em memória), sendo assim defina um modelo de dados que restrinja o acesso aos LOBs.

Já vi sistemas comercias onde para saber o status de uma NFe sempre o conteúdo da NFe (um LOB) é lido causando problemas crônicos de performance (erro no modelo de dados).

[Autor]

Posts