Menu de navegação

[fabiommirandaParticipante]

Os analistas e usuários dos sistemas estão reclamando que várias tabelas que no 9i apareciam ordenadas, após a migração para o 10g as tabelas mudaram a posição dos registros na mesma tela.

[vieriParticipante]

Normal.

No 10G isso foi acertado.

Mandas os desenvolvedores incluirem o order by corretamente.

[fabiommirandaParticipante]

me parece que na versao 9i ele tem um otimizador que ordena as querys , alguem tem alguma dica ?

[Marcos BragaParticipante]

Oi Fábio,

Observei muitos “problemas” como este, com reclamações dos desenvolvedores. E observando as queries que utilizavam, uma boa parte usavam ROWNUM para efetuar alguma operação.

Informei que isso não pode ser feito, pois se ativarmos algum tipo de desfragmentação de tabela, temos que habilitar ROW MOVEMENT e isso faz com que o ROWNUM (que é um registro único utilizado pelo Oracle) mude; assim as queries não retornavam a contento.

A solução foi mesmo a comentada pelo vieri; os desenvolvedores tiveram que arrumar as queries para que retornassem realmente o que queriam.

[]s
Braga

[vieriParticipante]

Fábio vai ter que incluir o order by!

Alegue para os desenvolvedores que não existe nada que pode ser feito…
Eles deviam ter escrito em SQL ANCSI se quisessem nunca dar manutenção nesse sentido.
faz parte do trabalho deles dar manutenção em código.

O hint de ordenação a que vc se referiu é para ordernação de
índices em joins, ou seja , qual ele irá ler 1°, para efeito de performance,
nada haver com esse problema.

ORDERED Hint

The ORDERED hint instructs Oracle to join tables in the order in which they appear in the FROM clause. Oracle recommends that you use the LEADING hint, which is more versatile than the ORDERED hint.

When you omit the ORDERED hint from a SQL statement requiring a join, the optimizer chooses the order in which to join the tables. You might want to use the ORDERED hint to specify a join order if you know something that the optimizer does not know about the number of rows selected from each table. Such information lets you choose an inner and outer table better than the optimizer could.

The following query is an example of the use of the ORDERED hint:

SELECT /*+ORDERED */ o.order_id, c.customer_id, l.unit_price * l.quantity
FROM customers c, order_items l, orders o
WHERE c.cust_last_name = :b1
AND o.customer_id = c.customer_id
AND o.order_id = l.order_id;

[fabiommirandaParticipante]

Obrigado cara vou instruir os analistas aqui ….
vlw

[Rodrigo AlmeidaParticipante]

OPA!

Migrações de 8i,9i podem ocorrer isso sim para o 10g.

Principalmente na parte de NLS. E para ser mais preciso NLS_BINARY!

Abraços,

[CleitonHanzenParticipante]

Opá…

Pois entaum, esse é um problema bem comum em migração pra 10g, principalmente em aplicações legadas (onde os desenvolvedores geralmente se preocupam em desenvolver para um único banco/versão e ficam mal-acostumados com as facilidades).

Quando tive pela primeira vez este problema, a Oracle informou que o CORRETO é fazer o order by em todas as queries, isso para garantir que os dados sempre sejam retornados na ordem. Outra solução de contorno apresentada, é setar o parâmetro abaixo no init/spfile e dar stop/start do banco, porém não há garantias de que isso irá funcionar 100%.

Parâmetro:
“_gby_hash_aggregation_enabled” = false

[vieriParticipante]

Deêm uma lida nessa discussão antes de decidir qual decisão tomar.

Como tenho desenvolvedores a disposição eu mandaria alterar,
caso fosse um programa fechado e sem contrato de suporte e
sem problemas críticos de performance eu arriscaria alterar esse parâmetro a acompanharia o alert e a performance da base para ver se houve mudanças!

Salvo os trechos mais interessantes:

Re: Is it recomended to set _gby_hash_aggregation_enabled =FALSE
by Tim… » Wed Nov 14, 2007 4:12 pm

Hi.

As a general rule, you should not touch the parameters beginning with a “_” unless specifically told to do so by Oracle support.

If this gets you past your current issue, fine, but you really need to refactor your application so that you can run without this setting. You should consider this a temporary fix. Things like your record ordering issue are down to bad programming. The documentation clearly states that row order cannot be guaranteed unless you have an ORDER BY clause. The fact that some operations may currently perform an implicit ORDER BY does not mean you don’t have to add one yourself. The differences between 9i and 10g with the GROUP BY prove this.

Cheers

Tim…

Hi,
How are you Wasif?
Distinct and Group By clauses are not supposed to sort the result set. It was only the execution plan which oracvle 8i/9i optimizer has been using for group by and distinct which returned rows in sorte order and if some developer trusted group by OR distinct for sorting and didn’t use order by, its not Oracle fault (Oracle corporation says this).
I think the parameter you are talking about will give you behaviour of distinct same as it was in 9i and it will start returning the result in sorted order and using which you will be safing yourself from making many changes in the Application and it could also work for you but, you will be using efficient execution plan which oracle 10g uses.
As far as i know, the default value for this mentioned parameter is TRUE and i guess this is also the recommended value)

Regards

[jspaulonciParticipante]

Bom dia pessoal, estava lendo essa discussão e ela me interessa, pois irei fazer migração de 9i para 10g , the single instance para RAC, no meu caso é fácil, vou fazer exp imp pois a base não é tão grande, porem li reli e mesmo assim fiquei em dúvida.

Quando migramos de 9i para 10g os registros pode ficar em ordem diferente, na tabela, consequentemente a ordem das linhas no retorno de um select será diferente, a idéia é que os desenvolvedores coloquem order by nas instruções select para evitar este tipo de transtorno ?

Obrigado

Spaulonci

[Autor]

Posts