Aproveitando a dica do @pinceladasdaweb, dei uma lida no post e vou fazer uma tradução livre aqui, acrescentando meu ponto de vista e mais algumas dicas sobre SQL em um banco de dados relacional:

1. Defina seu banco de dados com cuidado
Um bom banco de dados é um banco de dados bem desenhado, que não gera tanto trabalho para buscar as informaçoes e que não guarda dados duplicados. É um banco que tem uma estrutura clara e com nomes de tabelas e campos identificáveis.

2. Otimize o que for necessário
Nem todos os SQL que utilizaremos devem e podem ser utilizados. Mas várias instruções podem e DEVEM ser otimizadas. Para o banco cada query tem um custo, e utilizando a ferramenta e EXPLAIN, que tem em praticamente todos os bons bancos de dados, podemos ver o que está afetando mais nossa query. Cuide os joins, linhas desnecessárias, igualdades incorretas, falta de indices, etc…

3. Use algo para agilizar
Utilizar um sistema de cache é sempre muito bom, e não apenas para as querys. Pois tudo que tem que ser gerado e processado gera custo e tempo, sendo que se você já tem um resultado pronto, do que você quer, sendo q o mesmo já foi processado a algum tempo atrás é muito bom ! Isto acaba com o tráfego na rede e no processamento do banco.
No site ele cira algumas ferramentas interessantes. E devem ter outras também.

4. Não selecione o que você não precisa
Corretíssimo! Nada de “select * …” por ai heim !
Coloque na projeção do SQL ( aquela parte depois do “select” e antes do “from” ) apenas os campos que você vai precisar. Isto nos além de gerar menos custo para o banco, acaba organizando nosso retorno e padronizando a aplicação.

5. Limite o numero de linhas a serem retornadas
Geralmente o usuário final, aquele que está vendo aquela listagem de algum item na tela, não vai precisar de todos os itens que tem cadastrado na tabela. Então use paginação ! Sempre ! Limitando o número de linhas a serem retornadas do banco o custo cai ser bem menor e a resposta vai ser mais rápida. O uso de Ajax ( para web ) geralmente ajuda bastante nestes casos.

6. Não coloque chamadas ao banco dentro de loops
Organize seu código, que eu duvido que você não conseguirá unir todos os dados necessários em apenas 1 ou 2 chamadas no banco, ao invés de colocar a query em um loop. Lembre-se, que o quanto menos tiver que acessar o banco melhor !

7. Utilize JOINS ao invés de SUBQUERYs
Concordo ! A não ser em casos muito, muito complexos, não utilize subquerys, elas são muito mais pesadas e são executadas 1 vez para cada linha retornada da nossa query pai, gerando assim um custo enorme para o banco. E subquerys na projeção NEM PENSAR ! NUNCA !

8. Utilize os wildcards
Até certo ponto eu levo isto como uma feature mesmo, do SQL ansi, com o comando LIKE, do que um forma de otimização.

9. Utilize UNION ao invés de OR
Bem, eu não entendi direito o pq desta dica, até mesmo pq eu não utilizo o MySql, mas para mim isto não é válido, pois na grande maioria dos casos esta troca causará um aumento de custo ao banco, e não o contrário. Mas sempre teste sua query com mais de uma forma, talvez este seja seu caso.

10. Use Índices
Sim ! Use indices no seu banco. Mas além das PK e os indices para elas criados automaticamente, utilize somente indices em campos e tabelas que necessitarão deles. Se un indice não é utilizado em nenhum momento, em nenhuma query, exclua-o, pois ele estará gerando trabalho em vão para o banco atualizá-lo.
Como eu faço:
- Rodo a query e analiso
- Crio indices onde eu acho que deve ser criado
- Rodo a query e analiso
- Crio, altero e excluo mais algins indices onde eu acho que deve
- Rodo a query e analiso
- Excluo todos os indices que não estão sendo utilizados
- Rodo a query e analiso
- Pronto!

Geralmente estes poucos passos bastam controlar a criação de indices.

11. Triggers – Tome cuidado com elas
Elas podem nos ajudar muito, mas podem deixar o banco de dados lentão e até gerar dead-locks. Então pense bem se é realmente necessário criar tal procedimento como uma trigger.

12. Sequences/Autoincremento
Estes campos nos facilitam muito o controle das PKs e não oneram em trabalho do banco.

13. Procedimentos pesados, Batch
Estes sim eu aconselho a, sempre que possível, serem executados dentro banco.
A linguagem que roda dentro do banco de dados é muito mais ágil ao trabalhar com os dados do que ficar trazendo e enviando dados do banco até a aplicação. E isto em procedimentos que geram informações de cálculos violentíssimos, ou controles com muitos dados, e que podem demorar para rodar, podem ser colocados dentro do banco.
No PostgresSQL por exemplo, temos não somente o Pl/pgSQL, mas sim inúmeras linguagens que trabalham dentro do DB, no Oracle tem o PL/SQL, e assim vai…

No mais é o seguinte:

• Sempre teste suas querys com mais de uma forma, trocando campos de lugar, trocando a ordem dos joins e das filtragens.
• Quantos aos frameworks de banco, leia bastante na documentação como fazer para agilizar as pesquisas.
• Aprenda a alterar as principais configurações do seu banco de dados para que ele trabalhe melhor para sua aplicação, sendo que ela faz mais gravação de dados ou mais leitura de dados.
• A infra estrutura do ambiente de produção todo é muito relevante, tanto para a aplicação como para o banco. Sempre ter o banco em uma máquina separada da aplicação é ótimo!

Related posts:

1. Vim e dicas…
2. Aplicações para XFCE
3. Editor para Python/Django

SQL> startup
ORACLE instance started.

Total System Global Area 2348810240 bytes
Fixed Size                  2022536 bytes
Variable Size             436208504 bytes
Database Buffers         1895825408 bytes
Redo Buffers               14753792 bytes
Database mounted.
ORA-01172: recovery of thread 1 stuck at block 17589 of file 2
ORA-01151: use media recovery to recover block, restore backup if needed

Wow.. jah pensei, putz, vou ter um bom trabalho durante o dia todo para recuperar o banco.. pq com o Oracle é sempre assim… Ledo engano !

Bastou pedir ajuda aos universitários e cheguei até esta resposta. Então fiz o seguinte:

SQL> shutdown immediate
Database dismounted.
ORACLE instance shut down.
SQL>; startup mount
ORACLE instance started.

Total System Global Area 2348810240 bytes
Fixed Size                  2022536 bytes
Variable Size             436208504 bytes
Database Buffers         1895825408 bytes
Redo Buffers               14753792 bytes
Database mounted.
SQL>; recover database
Media recovery complete.
SQL> alter database open ;

Database altered.
SQL> exit;

Perfeito… resolveu ! Ufa !
Pronto para outra.. hehehe

Related posts:

1. ORA-12519

Já aproveitando, o script tem alguns exemplos interessantes, como strings gigantes, gravação em arquivo, loop while, método “format” da string e claro, como conectar e retornar queryes do Oracle.

Aproveitem e comentem tb …

Link: http://wiki.berlotto.blog.br/index.php?title=Conex%C3%A3o_com_Oracle

Related posts:

1. Oracle – Explain plan
2. Oracle com JDBC thin/OCI driver
3. Oracle – IMP/EXP – Como alterar as tablespaces

Quando está ocorrendo este erro, intermitentemente ao se conectar no Oracle, provalmente foi o número de PROCESSES/SESSIONS/TRANSACTIONS que estourou.
Para verificar se foi isto mesmo, você pode ver os limites do seu banco com o SQL abaixo:

select RESOURCE_NAME, CURRENT_UTILIZATION, MAX_UTILIZATION from v$resource_limit;

Caso sim, então altere seu banco , aumentando o nro de PROCESSES possíveis, lembrando sempre que o numero de SESSIONS e TRANSACTIONS são derivados de PROCESSES, desta forma:

Sessions = (1.1 * Processes)+5
Transactions = (1.1 * Sessions)

Veja na documentação da Oracle:
PROCESSES
SESSIONS
TRANSACTIONS

Para alterar faça o seguinte:
. conecte como sys
. ALTER SYSTEM SET PROCESSES=300 SCOPE=SPFILE;
. ALTER SYSTEM SET SESSIONS=335 SCOPE=SPFILE;
. ALTER SYSTEM SET TRANSACTIONS=369 SCOPE=SPFILE;
. reiniciar o banco
. Validar novamente se as alterações sustiram efeito com o SQL acima.

PS. 300 é um bom número para processos, que é o dobro do padrão. Mas caso necessário ainda mais, e se você tem bastante maquina disponivel, pode até colocar mais …

Related posts:

1. Como trocar o numero maximo de conexões ativas simultêneas com o Oracle 10g
2. DBA / Dica de Oracle
3. PostgreSQL

Mas depois de muitas tentativas de achar a melhor maneira de fazer isto, acabei editando um arquivo .dmp com um editor de textos, no meu casos o Notepad++. E o que acabo encontrando dentro do arquivo além de escritos binários ? Um monte de comandos DDL ! hehehe Isto mesmo … os comandos DDL daquele export efetuado é gravado como texto no arquivo de dump do Oracle.

Sendo assim, pensei…
Por que não editá-lo ??

Sim ! Editei-o-o-o !

Fiz um replace-all do nome da tablespace incorreta, juntamente com as aspas para não ter erro, para o nome da minha tablespace correta.

Salvei ! Fechei ! Importei !
Advinha ? FUNCIONOU perfeitamente… parecia um dump original do Oracle ! hehehe

Só não sei se outro tipo de alteração nos arquivos de dump irão funcionar como este, mas a troca da tablespace funcionou !

Resumo da história:

--Exportar banco
exp [usuario]@orcl file=[path]/dumporacle.dmp .......
--Editar o dump dumporacle.dmp e trocar o nome das tablespaces incorretas para as corretas.
--Importar o dump
imp [usuario]@orcl file=[path]/dumporacle.dmp ......

Falow pessoal !

Related posts:

1. Como obter hora atual em minutos no Oracle 10g
2. Como trocar o numero maximo de conexões ativas simultêneas com o Oracle 10g
3. DBA / Dica de Oracle

Conexão ao Oracle
Banner do banco ao conectar
JSP
JServer
JSQL
Stored Procedures em Java

Divirtam-se…

Related posts:

1. DBA / Dica de Oracle
2. ORACLE SQL Developer
3. Como trocar o numero maximo de conexões ativas simultêneas com o Oracle 10g