Menu de navegação

[eversonpizaParticipante]

Pessoal,

Tenho algumas instancias aqui de desenvolvimento e testes, que o pessoal acaba criando muitos schemas e não dropando, com isso o dicionário de dados ficou todo zuado, para terem uma idéia tenho uma instancia onde a tablespace system tem 5GB.

Com isso tenho dois problemas.

1 – A performance em views do dicionário de dados ficaram horríveis, sei que o disco não é muito eficiente, mas mesmo assim se comparado com outras instancias percebemos que esta fora da realidade o tempo de resposta.

2 – A tablespace system esta com 100% de uso, e o pessoal precisa criar mais bases, dropei vários schemas com muitos objetos, e mesmo assim o oracle não liberou ‘espaço’, cada hora dá erro em uma tabela do dicionário, as mais comuns são OBJ$ e e VIEW$. Acredito que não tenha liberado o bloco para insert por não ter atingido o pctused.

Se não fossem tabelas do SYS eu daria um ‘move’ e estaria tudo resolvido, mas como é SYS não sei como fazer, alguém tem alguma sugestão?

Obrigado,
Everson.

[Douglas Paiva de SousaParticipante]

Executa este select, para saber o tamanho dos objetos de cada schema, aí depois disso você vai vendo qual você pode dropar e qual não pode, feita a limpeza sugiro dar um reorg na base, de preferencia exportando e importando novamente os objetos caso seja possivel.

select owner, segment_type, round(sum(bytes)/1024/1024,2) as "Size"
from dba_segments
group by owner, segment_type
order by 1, 3 desc;

Outro ponto que você falou é que sua tablespace SYSTEM está com 5GB veja se nela tem objetos de outros usuários ou se você está com a trilha de auditoria ligada esses são pontos que podem refletir diretamente na performance do seu banco.

[Fábio PradoParticipante]

eversonpiza, me parece que seu problema nao tem relação com fragmentação do DD, pois 5GB de tablespace SYSTEM não é muita coisa!

Sugiro que veja se o SYSTEM não estourou tamanho de armazenamento do tablespace ou se vc tem blocos corrompidos nele. Para verificar blocos corrompidos vc pode executar no RMAN o comando VALIDATE DATABASE.

[]s

Fábio Prado
http://www.fabioprado.net

[eversonpizaParticipante]

Fábio,

Realmente 5GB pode não ser uma tamanho absurdamente grande, mas poucas vezes vi uma tablespace SYSTEM, que só tenha objetos do SYS, com esse tamanho.

O problema não é bloco corrompido, a tablespace realmente esta com 100% do seu espaço alocado, até tenho mais espaço em disco, mas não queria deixar a TS crescer infinitamente, queria tentar reaproveitar o espaço que ela já esta usando, como é base de desenvolvimento o pessoa cria e remove schemas direto, e são schemas com centenas de objetos, e acredito que como toda tabela ‘comum’ as do dicionário também sofram com esse grande volume de DML’s.

DPaiva,
Nas outras tablespaces tem espaço livre, dropar usuários ‘grandes’, não mudaria o meu cenário, o problema é mesmo apenas na tablespace SYSTEM, e lá só tem objetos do owner SYS, para vc ter uma idéia, os maiores objetos são:

select * from
(select segment_name, round(bytes/1048576) MB from dba_segments where owner = 'SYS' and tablespace_name = 'SYSTEM' order by bytes desc)
14:46:43 3 where rownum <= 10;

SEGMENT_NAME	MB
VIEW$	474
C_OBJ#	464
C_OBJ#_INTCOL#	272
I_COL1	272
IDL_UB1$	256
I_DEPENDENCY1	208
I_COL2	192
SOURCE$	176
I_COL3	168
C_COBJ#	152

10 rows selected.

Elapsed: 00:04:30.11

Ps.: reparem no tempo de resposta deste ‘simples’ select

[Douglas Paiva de SousaParticipante]

Relmente 4:30 para uma query simples, é algo muito estranho, ainda mais que os maiores objetos que você tem na TBS SYSTEM não têm tamanhos muito grande. Você já olhou a distribuição de memória deste servidor? Veja também no alert.log se tem alguma mensagem diferente do habitual.

[eversonpizaParticipante]

Oi Douglas,

Não acredito que seja problema de memória, tenho outras instancias no mesmo servidor, e sempre as mesmas que são lentas, no alert não tem nada.

Outro dia gerei um trace de uma consulta parecida com essa, e vi que quase todo tempo é consumido em I/O.

Sei que o disco é lento, mas em outras instancias com SYSTEM de +/- 2.5G, e volume menor de criação de schemas a performance é muito melhor, por isso pensei na desfragmentação, só que a unica forma que conheço de desfragmentar o dicionário é dropar a instancia e criar novamente.

Att.
Everson

[Douglas Paiva de SousaParticipante]

Everson,

Acredito que agora antes do Tunning temos um trabalho investigativo a fazer, dê uma olhada no link abaixo, acredito que ele possa te ajudar.

http://docs.oracle.com/cd/B28359_01/server.111/b28275/tdppt_partthree.htm#sthref254

[Ricardo Portilho ProniParticipante]

Cara, o tamanho das suas tabelas do SYS referentes a objetos não estão normais.
500MB para a VIEW$ e C_OBJ# não é normal.
Parece que um desenvolvedor maluco (pleonasmo) executou uma criação de objetos em LOOP com EXECUTE IMMEDIATE, sei lá. É meu chute.

E sugiro você criar outro banco, exportar o que precisa deste banco, e importar no novo.

[eversonpizaParticipante]

Olá Ricardo,

O problema não foi que um desenvolvedor saiu criando objeto com loop, essa base de desenvolvimento é compartilhada com algumas dezenas de desenvolvedores, e cada um cria sua ‘base’ própria, o problema é que o povo não tem costume de dropar depois q termina o uso, o queixa a instancia cheia de lixo. Para ajudar, o sistema tem muitas views e stored procedures, com isso o dicionário ficou realmente fora do normal.

Para vc ter uma idéia, hoje temos mais de 350 schemas criados, o normal seria menos da metade, na ultima ‘faxina’ que fiz, dropei quase 200.

Pensei em exportar tudo e importar novamente, mas queria saber se tem uma forma mais ‘fácil’ e menos invasiva de desfragmentar o dicionário.

Obrigado,
Everson

[Autor]

Posts