Por Infoworld, EUA

Será que os desenvolvedores estão piorando na medida em que os bancos de dados amadurecem ou eles simplesmente não são capazes de evoluir sus habilidades no mesmo ritmo das demandas? De qualquer maneira, o Oracle está ajudando muito os administradores de banco de dados a descobrir e lidar com código devorador de recursos.

Para começar, o banco de dados 11g acrescenta capacidades de auto-aprendizagem ao tuning de SQL automático do Oracle. Agora o engine detecta instruções SQL de alta carga e as salva para tuning durante uma janela de manutenção. Ele pode aplicar algumas correções automáticas ou sugerir mudanças estruturais.

Se você está em dúvida quanto a permitir que o engine faça tuning demais, pode simplesmente deixá-lo capturar suas consultas e sugerir correções. Depois, se o engine estiver certo na maioria das vezes, você pode começar a confiar mais nele.

Um problema é que o Oracle não pode levar em conta toda a sua carga de trabalho e, por isso, talvez sugira mudanças que danificariam seu fluxo normal para uma consulta que é executada apenas de vez em quando.

Teste de Estresse - Oracle 11g
Teste do Oracle 11g – Primeira Parte
Teste do Oracle 11g – Result Cache
Teste do Oracle 11g – Snapshot Standby
Teste do Oracle 11g – Active Data Guard
Teste do Oracle 11g – Real Application Testing
Teste do Oracle 11g - Advanced Compression

Existe mais de uma maneira de quantificar uma carga de trabalho descontrolada e o Oracle é capaz de lidar com isso. Quando as cargas de trabalho entram em colapso, normalmente está em uma das áreas do servidor: CPU, memória ou I/O de disco. Em geral, os reguladores de recursos quantificam uma carga de trabalho descontrolada medindo CPU ou memória, mas o Oracle Database 11g também institui limites de I/O por sessão.

Estes limites de I/O permitem que você especifique um valor máximo (seja em megabytes ou solicitações de I/O) de trabalho que as conexões estão autorizadas a realizar no servidor. Os limites de I/O são um acréscimo muito importante porque estes sistemas podem atingir o limite do disco com muita facilidade e o capping de recursos de CPU ou memória não aborda adequadamente a contenção de disco.

Os limites de I/O também podem ajudar os administradores de banco de dados a impedir consultas de longa execução. Visto que não existe um meio de definir nativamente uma política que verifica se uma consulta utilizou 20% da CPU durante 20 minutos, por exemplo, os administradores de banco de dados, muitas vezes, criam suas próprias verificações e depois fazem com que o código execute alguma coisa com base nos resultados. Poder limitar o consumo total de I/O significa não ter mais que gerenciar estas verificações manualmente.

E, como sempre, você pode mover estes consultas de longa execução para um grupo de recursos de prioridade mais baixa à medida que elas se tornam problemáticas. Se você for criar SQL que retarda o sistema, então receberá menos recursos a fim de não afetar outros. E, como resultado, sua consulta levará muito mais de tempo.