Hva er råttent med denne queryen?

[JOB]

(SQL-noob her)

Jeg har et program med en query som spør en MS SCCM-database. Queryen gjør at programmet får outofmemory.

Noen som ser hva som er galt med denne?

 

SELECT NIC.*, CONF.DefaultIPGateway0,CONF.DHCPEnabled0,
CONF.[DHCPLeaseExpires0],CONF.[DHCPLeaseObtained0],
CONF.[DHCPServer0],CONF.[iPEnabled0],CONF.[iPAddress0],
CONF.[iPFilterSecurityEnabled0],CONF.[iPPortSecurityEnabled0], CONF.[iPSubnet0]
FROM [v_GS_NETWORK_ADAPTER] NIC
LEFT OUTER JOIN [v_GS_NETWORK_ADAPTER_CONFIGURATION] CONF ON NIC.MACAddress0 = CONF.MACAddress0

[quantum]

kan du prøve med select top 500 NIC.* .... for å se hva du egentlig får ut? Høres ut som du produserer et eller annet kartesisk produkt, kan det være at MACAdress0 ikke har unik index?

[JOB]

Kjører jeg med top 500 rett i MSSQL Server Management Studio får jeg ut en helt normal liste. Det går også fint å kjøre med top 500 fra applikasjonen. (Å kjøre uten top 500 rett i Studio tør jeg ikke. Sannsynligvis går det bra, men det er nok svært upoppulært hvis jeg mot formodning tar ned basen, så det måtte jeg avklart først.)

Endret 9. juni 2018 av JOB

[quantum]

Kjører jeg med top 500 rett i MSSQL Server Management Studio får jeg ut en helt normal liste. Det går også fint å kjøre med top 500 fra applikasjonen. (Å kjøre uten top 500 rett i Studio tør jeg ikke. Sannsynligvis går det bra, men det er nok svært upoppulært hvis jeg mot formodning tar ned basen, så det måtte jeg avklart først.)

 

Nå vet ikke jeg hva du mener med en helt normal liste. Men det må være et eller annet som gjør at denne listen blir "uendelig" lang når du ikke har med begrenseninger. Og hvis tabellene ikke er "uendelig lange" hver for seg, så må det være slik at spørringen din på et eller annet vis produserer "alle mulige" kombinasjoner av rader fra de to tabellene. Det kan jo skje av årsaker nevnt over, og som du ikke gir oss noen videre opplysninger om.

[JOB]

Hehe, nei, en normal liste er vel svært upresist:) Det jeg mener er at jeg med top 500 får ut et resultat på 500 rader uten at noe ser unormalt ut. (Men som sagt er jeg ikke veldig sql-vant.) Hver av tabellene har ca  54000 rader. 

[quantum]

Det var vel ikke akkurat det jeg ville kalle en presisering. Og det jeg spør om ang index svarer du heller ikke på. 

[JOB]

Hei igjen og takk for at du svarer! Jeg må nok ha det inn med teskje:

"kan du prøve med select top 500 NIC.* .... for å se hva du egentlig får ut?"

- Hva skal jeg se etter?

"Høres ut som du produserer et eller annet kartesisk produkt, kan det være at MACAdress0 ikke har unik index?"

- Hvordan ser jeg om MACAddess0 ikke har unik index?

[quantum]

Heisann, hva du skal se etter er uventa rader i resultatet ditt. Jeg vet jo ikke helt nøyaktig hva du egentlig vil ha ut, eller hva du har i tabellene, så nøyaktig hva du skal se etter kan jeg ikke si. Men tanken min var at dersom join-kolonnene (Macaddress) har repeterende verdier kan resultatsettet få flere rader enn tabellene har. Har kolonnene unik index kan vi utelukke det, men du kan også kjøre en spørring og få ut eventuelle repeterende forekomster, noe a'la:

 

select count(macaddress), macaddress from tabellen group by macaddress having count(macaddress) > 1;

 

Hvis tabellene inneholder historiske data vil jo macaddress i conf ikke bli unik. Det kan jo være tilfellet conf-tabellen, siden den har kolonnene leseobtained og leaseexpired. Men siden den har omtrent like mange rader som nic-tabllen er det kanskje ikke sånn? I nic-tabellen er kanskje macaddress primærenøkkel? 

 

Tror egentlig du må fortelle hva tabellene er ment å inneholde også, samt hva det er du vil ha ut for å komme videre.

Endret 11. juni 2018 av quantum

[RulleRimfrost]

left outer join er en litt uvanlig query om høyresiden er kun en rad, som ofte skal funke som et filter. Sikker på det ikke skal vær vanlig join?

[quantum]

Hvis nic er nic og conf egentlig er dhcp-lease-rader, altså helt vanlig en-til-mange, hadde sikkert en inner join gjort susen. Men det vet vi jo ikke.