Vă mulțumim pentru susținere

Ați întâlnit vreodată o interogare pe care SQL Server nu a reușit să o execute deoarece a făcut referire la prea multe tabele?

Ați văzut vreodată mesajele de eroare de acolo?

- SQL Server 2000

     

Nu s-a putut aloca tabelul auxiliar pentru rezoluția de vizualizare sau funcție   Numărul maxim de tabele dintr-o interogare (256) a fost depășit.

     

- SQL Server 2005

     

Prea multe nume de tabele în interogare. Valoarea maximă admisă este 256.

Dacă da, ce ați făcut?

Renuntat? A convins clientul să-și simplifice cererile? Denormalizați baza de date?


@ (toată lumea vrea să postăm interogarea):

  1. Nu sunt sigur dacă pot lipi 70 kilobytes de cod în fereastra de editare a răspunsului.
  2. Chiar dacă reușesc acest lucru, acest lucru nu va fi de ajutor, deoarece acest cod de 70 de kilobyte va face referire la 20 sau 30 de vizualizări pe care ar trebui să le post, de altfel codul va fi lipsit de sens.

Nu vreau să sune așa cum mă laud aici, dar problema nu este în întrebări. Interogările sunt optime (sau cel puțin aproape optime). Am petrecut nenumarate ore optimizarea acestora, cautand fiecare coloana si fiecare masa care poate fi indepartata. Imaginați-vă un raport care are 200 sau 300 de coloane care trebuie umplut cu o singură instrucțiune SELECT (pentru că așa a fost proiectat acum câțiva ani când a fost încă un raport mic).

0
adăugat editat
Vizionările nu vor ajuta. Tabelele utilizate în vizualizări sunt de asemenea limitate.
adăugat autor Marek Grzenkowicz
Utilizați SQL Server 2000 SP3?
adăugat autor Stu
Ați putea să creați câteva viziuni?
adăugat autor Calvin Allen

8 răspunsuri

Aș vrea să văd acea interogare, dar îmi imaginez că este o problemă cu un fel de iterator și, deși nu mă pot gândi la situații în care este posibil, pun pariu că este de la un rău timp / caz / cursor sau o tona de viziuni slab implementate.

0
adăugat
Nici un iterator de orice fel. Doar o singură instrucțiune SELECT.
adăugat autor Marek Grzenkowicz

Postați interogarea: D

De asemenea, mă simt ca una dintre problemele posibile ar putea fi o tona (citiți 200+) de tabele de nume / valori care ar putea condensa într-un singur tabel de căutare.

0
adăugat

@chopeen Puteți schimba modul în care calculați aceste statistici și păstrați în schimb un tabel separat al tuturor statisticilor per-produs .. atunci când este plasată o comandă, treceți prin produse și actualizați înregistrările corespunzătoare în tabelul de statistici. Acest lucru ar schimba o mulțime de sarcină de calcul la pagina de control, mai degrabă decât să ruleze totul într-o interogare imensă atunci când rulează un raport. Desigur, există unele statistici care nu vor funcționa în acest fel, de ex. urmărirea următoarelor achiziții ale clienților după achiziționarea unui anumit produs.

0
adăugat

Pentru SQL Server 2005, aș recomanda folosirea variabilelor de tabel și construirea parțială a datelor în timp ce mergeți.

Pentru aceasta, creați o variabilă de tabel care reprezintă setul de rezultate finale pe care doriți să-l trimiteți utilizatorului.

Apoi, găsiți masa principală (spuneți tabelul de comenzi din exemplul de mai sus) și trageți aceste date, plus un pic de date suplimentare, care se referă doar la o singură dată (numele clientului, numele produsului). Puteți face o SELECT INTO pentru a pune acest lucru direct în variabila tabelului.

De acolo, iterați prin tabel și pentru fiecare rând, faceți o grămadă de interogări SELECT mici, care preiau toate datele suplimentare de care aveți nevoie pentru setul de rezultate. Introduceți-le în fiecare coloană în timp ce mergeți.

După finalizare, puteți face apoi un simplu SELECT * din variabila tabelă și returnați acest set de rezultate utilizatorului.

Nu am nici un număr de greu pentru acest lucru, dar au existat trei cazuri distincte pe care am lucrat până în prezent în cazul în care face aceste interogări mai mici, de fapt, a lucrat mai repede decât a face o interogare de selectare masivă, cu un buchet de se alatura.

0
adăugat

I have never come across this kind of situation, and to be honest the idea of referencing > 256 tables in a query fils me with a mortal dread.

Prima întrebare ar trebui să fie probabil "De ce atât de mulți?", Urmată îndeaproape de "ce biți de informații nu trebuie ? Aș fi îngrijorat că suma datelor returnate dintr-o astfel de interogare va începe să influențeze performanța aplicației destul de grav.

0
adăugat
Imaginați-vă un client care dorește să vadă o listă (în grilă) a articolelor din magazinele sale, împreună cu o mulțime de informații (de exemplu despre prima comandă a fiecărui element, despre ultima comandă, despre prima livrare, despre ultima livrare, despre clienții care o cumpără, despre costurile livrării, ...). Crede-mă, este posibil, am văzut-o. Și trebuia să mă descurc. :) Da, impactul asupra performanței poate fi grav în astfel de situații.
adăugat autor Marek Grzenkowicz

Acest lucru se va întâmpla tot timpul când se scriu rapoarte de raportare a serviciilor pentru instalațiile Dynamics CRM care rulează pe SQL Server 2000. CRM are o schemă de date bine normalizată, care are ca rezultat o mulțime de conexiuni. Există de fapt o remediere rapidă care va limita de la 256 la 260: http://support.microsoft .com / kb / 818406 (întotdeauna am crezut că este o glumă bună din partea echipei SQL Server).

Soluția, așa cum se cuvine lui Dillie-O, este de a identifica "sub-legături" potrivite (de preferință cele care sunt folosite de mai multe ori) și de a le transforma în variabilele temp-table pe care le utilizați apoi în principalele dumneavoastră conexiuni. Este un PIA important și adesea ucide performanța. Îmi pare rău pentru tine.

@Kevin, iubesc că tee - spune totul :-).

0
adăugat

Am avut aceeași problemă ... cutia mea de dezvoltare rulează SQL Server 2008 (vizualizarea a funcționat bine), dar pe producție (cu SQL Server 2005) vizualizarea nu a făcut-o. Am ajuns să creez vizualizări pentru a evita această limitare, folosind vizualizările noi ca parte a interogării în vizualizarea care a aruncat eroarea.

Un fel de prostie având în vedere execuția logică este aceeași ...

0
adăugat
Este ciudat faptul că a ajutat - în măsura în care știu, tabelele utilizate în vizualizări sunt limitate. Utilizați vizualizări indexate?
adăugat autor Marek Grzenkowicz

A avut aceeași problemă în SQL Server 2005 (a lucrat în 2008) când am vrut să creez o vizualizare. Am rezolvat problema creând o procedură stocată în locul unei vizualizări.

0
adăugat