[Oracle]Wordt de index gebruikt bij een database link?

[Maasluip]

Ik doe in oracle een select over twee tabellen die in twee verschillende instances staan:

SQL:

select *
  from tab1 t1, tab2@inst2 t2
 where t1.col = t2.col

Nu staat me iets bij dat als je een select over een databaselink doet de index van de tabel in de link nooit gebruikt wordt, klopt dat? (Het kan zijn dat ik in de war ben met views, dat daar geen indexen worden gebruikt?)

Als het klopt, heeft het dan ook geen zin om een index op de kolom van de lokale tabel te maken?

[trogdor]

Wat je bedoelt neem ik aan is dat de index niet voor de join gebruikt wordt.
Bij een normale join wordt eerst op de indexen een join gedaan, en worden dan pas de reccords opgehaald. Maar omdat een van de tables in een andere instance staat worden nu eerst alle reccords opgehaald en dan pas de join gedaan. dat is inderdaad minder effectief.

[mkleinman]

over een dbllink pakt oracle (wanneer er uiteraard een index beschikbaar is) gewoon netjes de index.

En inderdaad als je een view zelf maakt gebruikt de view wel de index maar als je een link legt tussen een tabel en een view pakt hij vaak geen index.

[ Voor 45% gewijzigd door mkleinman op 24-12-2003 14:31 ]

[Maasluip]

Dus common sense zegt dat je de select doet vanuit de instance waar de grootste tabel staat.

edit:
Hmm, op de een of andere manier was ik even blind voor de post van mkleinman64

Het probleem is een beetje dat de select nu nog niet compleet is en al 10 minuten duurt. Als ik een derde tabel die ik nodig heb (en die niet in de instance met de grootste tabel staat) erbij join dan is de performance helemaal naadje.
Gelukkig dat die select maar eens per maand gedaan hoeft te worden.

[ Voor 12% gewijzigd door Maasluip op 24-12-2003 14:55 ]

[mkleinman]

mdeen schreef op 24 december 2003 @ 14:39:
Dus common sense zegt dat je de select doet vanuit de instance waar de grootste tabel staat.

edit:
Hmm, op de een of andere manier was ik even blind voor de post van mkleinman64

Het probleem is een beetje dat de select nu nog niet compleet is en al 10 minuten duurt. Als ik een derde tabel die ik nodig heb (en die niet in de instance met de grootste tabel staat) erbij join dan is de performance helemaal naadje.
Gelukkig dat die select maar eens per maand gedaan hoeft te worden.

Heb je al eens geprobeerd om de query op te bouwen zoals je hem wilt hebben en dan de explain plan te bekijken? Bijv met plsqldeveloper kan je een query bouwen executen en met F5 de explain plan bekijken. Meestal kan je in de explain plan heel snel zien waarom je query zo traag is.

Heb even snel een query in mekaar gezet van m'n eigen applicatie (absoluut NIET CDM compliant, dus niet raar opkijken van vreemde indexnamen/ pk/fk's etc ).



Het is even wennen maar je ziet vrij snel dat "table access full" zoveel mogelijk moet worden vermeden.

plsqldeveloper kan je een gratis trail van downloaden op http://www.allroundautomations.com. Trail versie is full functional en werkt 30 dagen.

Overigens zie ik nu net in je voorbeeld het volgende staan.

SELECT * FROM ....

Beter wat je kan doen is


SELECT <alias>.kolomnaam, <alias>.kolomnaam.

Het zal geen wereldschokkende performance verbetering tot gevolg hebben maar het zal wel iets helpen.

[ Voor 10% gewijzigd door mkleinman op 25-12-2003 11:39 ]

[Maasluip]

mkleinman64 schreef op 25 december 2003 @ 11:32:
[...]


Heb je al eens geprobeerd om de query op te bouwen zoals je hem wilt hebben en dan de explain plan te bekijken? Bijv met plsqldeveloper kan je een query bouwen executen en met F5 de explain plan bekijken. Meestal kan je in de explain plan heel snel zien waarom je query zo traag is.

[...]

Overigens zie ik nu net in je voorbeeld het volgende staan.

SELECT * FROM ....

Beter wat je kan doen is


SELECT <alias>.kolomnaam, <alias>.kolomnaam.

Het zal geen wereldschokkende performance verbetering tot gevolg hebben maar het zal wel iets helpen.

Ik zal de explain plan gaan bestuderen. PL/SQL developer krijg ik als het goed is in januari, samen met een nieuwe PC.
De select is nog wat uitgebreider, er komt nog een tabel bij en ik gebruik ook geen select *.

[justmental]

mkleinman64 schreef op 25 december 2003 @ 11:32:
Het is even wennen maar je ziet vrij snel dat "table access full" zoveel mogelijk moet worden vermeden.

Dat is een bekende misvatting, in veel queries is een full table scan juist op zijn plaats vanwege weinig beperkende voorwaarden in de selectie.
Veel belangrijker bijvoorbeeld is de volgorde waarin tabellen worden benaderd.

[Maasluip]

mdeen schreef op 30 december 2003 @ 08:36:
[...]

Ik zal de explain plan gaan bestuderen.

Hmm, cost, cardinality en bytes zijn bij mij niet gevuld. Moet je daarvoor in Oracle nog speciale opties aanzetten of werkt dit misschien pas bij nieuwere versies? (ik heb hier nog 7.3.4)

[justmental]

mdeen schreef op 30 december 2003 @ 09:46:
Hmm, cost, cardinality en bytes zijn bij mij niet gevuld. Moet je daarvoor in Oracle nog speciale opties aanzetten of werkt dit misschien pas bij nieuwere versies? (ik heb hier nog 7.3.4)

Dan draai je rule based, waarschijnlijk staat je optimizer wel op choose, maar heb je geen statistics op je tabellen/indexen.

[mkleinman]

justmental schreef op 30 december 2003 @ 09:17:
[...]

Dat is een bekende misvatting, in veel queries is een full table scan juist op zijn plaats vanwege weinig beperkende voorwaarden in de selectie.
Veel belangrijker bijvoorbeeld is de volgorde waarin tabellen worden benaderd.

De applicaties die ik ontwikkel komen Full table scans niet of nauwelijks voor. Ok als je een simpel 1 op 1 tabelletje bouwt heb je een full table scan die totaal niet interessant is qua performance.

Wanneer je met 3/4 of meer joins gaat werken en je hebt 1 of meerdere Full table scans dan is die query hoogstwaarschijnlijk te optimaliseren door of de volgorde van de joins te veranderen of evt een extra index te introduceren.

Hmm, cost, cardinality en bytes zijn bij mij niet gevuld. Moet je daarvoor in Oracle nog speciale opties aanzetten of werkt dit misschien pas bij nieuwere versies? (ik heb hier nog 7.3.4)

WOW.. 7.3.4 nog? da's bijna antiek Laatste keer dat ik echt met 7.3.4 aan het werk ben geweest is inmiddels ruim 4 jaar terug.

Maar verder on topic. Vermoedelijk moet je statistics draaien van je tabellen.

Dat doe je met "ANALYZE TABLE <tabelnaam>". Vraag anders ff een DBA'er die dit voor je wil doen.

[ Voor 29% gewijzigd door mkleinman op 31-12-2003 17:34 . Reden: wat taalvouten ]

[Maasluip]

mkleinman64 schreef op 31 december 2003 @ 17:28:
[...]

WOW.. 7.3.4 nog? da's bijna antiek Laatste keer dat ik echt met 7.3.4 aan het werk ben geweest is inmiddels ruim 4 jaar terug.

Maar verder on topic. Vermoedelijk moet je statistics draaien van je tabellen.

Dat doe je met "ANALYZE TABLE <tabelnaam>". Vraag anders ff een DBA'er die dit voor je wil doen.

Dat zal ik eens proberen. Eerst kijken of ik daartoe gerechtigd ben.

En om nog maar effe over oude Oracle DB's door te gaan: we draaien het magazijnsysteem hier nog op 7.1.5.

Het eerste magazijnsysteem dat ik (mee) geïnstalleerd heb draaide ook 7.3.4.3. Dat was in 1999.

[justmental]

mkleinman64 schreef op 31 december 2003 @ 17:28:
De applicaties die ik ontwikkel komen Full table scans niet of nauwelijks voor. Ok als je een simpel 1 op 1 tabelletje bouwt heb je een full table scan die totaal niet interessant is qua performance.

Wanneer je met 3/4 of meer joins gaat werken en je hebt 1 of meerdere Full table scans dan is die query hoogstwaarschijnlijk te optimaliseren door of de volgorde van de joins te veranderen of evt een extra index te introduceren.

Dat is nou juist wat er vaak mis gaat, andersom is namelijk even vaak waar.
Een full table scan introduceren waar een query over een index loopt kan je net zo goed performancewinst opleveren, ook bij queries die over 10 tabellen lopen.
Met name export query's of rapportages over een groot deel van je dataset zijn meestal niet optimaal als ze helemaal over de indexen lopen.

Extra indexen zijn als je standaard elke foreign key indexed maar zelden nodig en daarbij ook nog eens nadelig voor je DML performance.