ORA-20005: object statistics are locked! Forever Locked!
O monitoramento da coleta de estatísticas de um banco é tão importante quanto a coleta em si. Muitos "DBAs" se preocupam apenas em implementar a tarefa de coleta de estatísticas, mas não se preocupam em monitorar se a coleta está sendo feita corretamente.
Um problema comum que impede a coleta das estatísticas é o erro ORA-20005: object statistics are locked. Normalmente isso acontece quando há uma interrupção brusca no processo de coleta, deixando a estatística de algum objeto "travada", como uma queda de energia, falha de hardware ou desligamento do servidor por algum outro motivo. Após ocorrer o problema ORA-20005, as estatísticas posteriores não serão mais concluídas, levando a uma queda de performance.
Entretanto a solução para o problema não é nada de outro mundo. Normalmente eu utilizo o pacote DBMS_STAT.UNLOCK_SCHEMA_STATS ('nome_do_esquema') para "destravar" o objeto que ficou preso. Caso queira ir direto ao problema, ou seja, o objeto em questão, pode consultar a visão DBA_TAB_STATISTICS:
select owner, table_name, stattype_locked from dba_tab_statistics where stattype_locked is not null;
E executar o pacote DBMS_STATS.UNLOCK_TABLE_STATS('OWNER','TABLE_NAME');
Não basta só executar. Tem que monitorar!
The gather statistics monitoring on a database is as important as the gathering itself. Many DBAs are just worry about implement a job to gather statistics, but don't monitor if this job is running ok.
A common problem that prevents the correct gathering statistics is the error ORA-20005: object statistics are locked. Usually this is caused by a sudden interruption on the gathering statistic process, letting the statistic of some object locked, as a power lost,
hardware fail or the server shutdown during the gathering process for some reason. After the ORA-20005 error the further statistics gathering will fail to complete, leading to a performance lost.
However the solution is not a complicated thing. Normally I execute the package DBMS_STAT.UNLOCK_SCHEMA_STATS ('OWNER') to "unlock" the object. But if you want to reach the origin of the problem you can look the database view DBA_TAB_STATISTICS:
select owner, table_name, stattype_locked from dba_tab_statistics where stattype_locked is not null; And execute the DBMS_STATS.UNLOCK_TABLE_STATS('OWNER', 'TABLE_NAME') package, passing the objects given by the view consulting.
Isn't enough just gathering statistics. You must monitor it!
Um problema comum que impede a coleta das estatísticas é o erro ORA-20005: object statistics are locked. Normalmente isso acontece quando há uma interrupção brusca no processo de coleta, deixando a estatística de algum objeto "travada", como uma queda de energia, falha de hardware ou desligamento do servidor por algum outro motivo. Após ocorrer o problema ORA-20005, as estatísticas posteriores não serão mais concluídas, levando a uma queda de performance.
Entretanto a solução para o problema não é nada de outro mundo. Normalmente eu utilizo o pacote DBMS_STAT.UNLOCK_SCHEMA_STATS ('nome_do_esquema') para "destravar" o objeto que ficou preso. Caso queira ir direto ao problema, ou seja, o objeto em questão, pode consultar a visão DBA_TAB_STATISTICS:
select owner, table_name, stattype_locked from dba_tab_statistics where stattype_locked is not null;
E executar o pacote DBMS_STATS.UNLOCK_TABLE_STATS('OWNER','TABLE_NAME');
Não basta só executar. Tem que monitorar!
The gather statistics monitoring on a database is as important as the gathering itself. Many DBAs are just worry about implement a job to gather statistics, but don't monitor if this job is running ok.
A common problem that prevents the correct gathering statistics is the error ORA-20005: object statistics are locked. Usually this is caused by a sudden interruption on the gathering statistic process, letting the statistic of some object locked, as a power lost,
hardware fail or the server shutdown during the gathering process for some reason. After the ORA-20005 error the further statistics gathering will fail to complete, leading to a performance lost.
However the solution is not a complicated thing. Normally I execute the package DBMS_STAT.UNLOCK_SCHEMA_STATS ('OWNER') to "unlock" the object. But if you want to reach the origin of the problem you can look the database view DBA_TAB_STATISTICS:
select owner, table_name, stattype_locked from dba_tab_statistics where stattype_locked is not null; And execute the DBMS_STATS.UNLOCK_TABLE_STATS('OWNER', 'TABLE_NAME') package, passing the objects given by the view consulting.
Isn't enough just gathering statistics. You must monitor it!
So they care about whatever it is that they are after, but they pay little to no attention to how the procedure that is running it? Is that what you said? does one have to monitor the program while it is running? Is that what you mean? Remember, I'm a psychology/fine arts major, they don't teach me as much of this stuff.
ResponderExcluir