Site-ul consultantilor SAP din Romania
http://sap-consulting.ro/phpbb/

Logical databases....
http://sap-consulting.ro/phpbb/viewtopic.php?f=1&t=237		 Pagina 2 din 2
Autor:  bogdancioc [ Mie, 26-Oct-2005 17:39 ]
Subiectul mesajului: 
Mihaela,

Solutia ta e foarte buna, adica pasii pe care i-ai parcurs sunt buni.
Da, aduci intai totul in memorie si apoi faci loop in memorie.
Da, inner join e preferabil unui select imbricat :)

E posibil sa nu fie insa si suficienti.

Ar mai fi un lucru care te poate ajuta, sa cresti chiar si mai mult viteza.

1. Fa selectia pe VBRP (eventual inner join cu VBRK), cu MATNR in clauza where.
2. observa timpii de raspuns.
3. creeaza un index pe VBRP (in standard nu exista) care sa contina campul MATNR.
4. repeta pasul 2. :wink:

Let us know!
Autor:  bogdancioc [ Mie, 26-Oct-2005 17:47 ]
Subiectul mesajului: 
bogdancioc scrie:
E posibil sa nu fie insa si suficienti.


De ce zic asta? Ruleaza in dezvoltare si apoi in quality, sau in productie.
Autor:  Mihaela [ Joi, 27-Oct-2005 11:19 ]
Subiectul mesajului: 
Salut! :D
Eu am facut select pe VBRK si inner join cu VBRP:))..
La pus index m-am gandit initial, dar am aici o nedumerire. Daca pun un index pe o tabela SAP ce influeanta are asupra celorlate procese din SAP ce folosesc aceasta tabela? Ca eu nu am avut curaj :shock:
Autor:  bogdancioc [ Vin, 28-Oct-2005 11:52 ]
Subiectul mesajului: 
Buna, Mihaela.

Fii fara frica, pune index daca tu crezi ca iti poate mari viteza unei aplicatii. Procesele de business nu vor suferi nici o schimbare din cauza asta.

Un index e folosit doar daca fraza SQL care se ruleaza pe tabela care il contine are o clauza WHERE de asa natura incat sa solicite acel index, altfel nu.

O tabela poate avea oricat de multi indecsi, pentru ca un index este nimic altceva decat o alta tabela de baze de date, care contine doar campurile selectate de tine ca si componente ale indexului (plus un pointer catre linia din tabela originala care contine aceasta valoare din linia de index), numai ca sortate (in ordine crescatoare, cred).

Cautarea pe tabela, atunci cand clauza WHERE contine campurile din index, va deveni o cautare in tabela index, unde de data aceasta se poate folosi un algoritm de cautare binara, si nu va trebui facuta o scanare secventiala a tabelei, cu comparari succesive, de pilda (aceasta fiind, evident varianta cea mai nerecomandata).

Pe de alta parte, indecsii cresc dimensiunea bazei de date, si scad viteza operatiilor de INSERT (trebuind actualizati corespunzator si toti indecsii asociati, iti dai seama).

Asa incat, ti-as recomanda, daca vrei sa pui indecsi, sa o faci pe acele tabele (campuri din tabele) care sunt interogate des, periodic sau pentru care viteza e un factor primordial (de pilda pentru procese in timp real sau mai stiu eu ce minuni).

Daca raportul tau pe VBRK & VBRP este rulat odata pe luna, de un user ratacit intr-o filiala din colt de tara :D nu te deranja, decat evident daca vrei sa experimentezi.

Daca asta e cazul :) , si orisicum, pentru a scapa de frica de care vorbeai, pune acel index. Pe VBRP nu cred sa existe oricum prea multi indecsi in sistemul vostru.
Autor:  Mihaela [ Vin, 28-Oct-2005 14:20 ]
Subiectul mesajului: 
Multumesc pt. raspuns !
Acum m-am luminat :).
Autor:  Vivas [ Mar, 22-Noi-2005 10:55 ]
Subiectul mesajului:  NU e nevoie sa faci nici un index pe material
In cazul in care doresti sa faci un select dupa material din lista cu facturi
trebuie sa folosesti alte tabele care exista in sap si care sunt indexate corespunzator. NU s-a intrebat nimeni poate de ce in tranzactia VF05 selectia se face obligatoriu dupa un camp - cod partener sau material. Raspunsul e simplu, ptr ca SAP a avut grija sa construiasca paralel 2 tabele indexate dupa cod partener si dupa material
VRKPA - index dupa partener
VRPMA - index dupa material
Autor:  MIRCEA BULAI [ Mar, 09-Mai-2006 15:15 ]
Subiectul mesajului:  Vizualizare vanzari
Hi, Mihaela.
Nu stiu daca subiectul mai e de actualitate , insa o fraza select de tipul celei de mai jos a durat cel mult 90-120 secunde pt circa 400 000 articole
*
SELECT VBRP~ARKTX VBRP~BRGEW VBRP~FKIMG VBRP~GEWEI VBRP~MATNR
VBRP~MEINS VBRP~NTGEW VBRP~VBELN VBRP~NETWR VBRP~WAVWR
VBRP~KZWI1 VBRP~MATKL VBRP~KURSK VBRP~FKLMG VBRP~VRKME
VBRP~PRSDT VBRK~VTWEG VBRK~KUNAG VBRK~FKART
VBRK~FKDAT VBRK~REGIO VBRK~VTWEG VBRK~FKSTO VBRP~SPART
VBRP~UMVKN VBRP~UMVKZ VBRK~WAERK VBRK~KNUMV VBRP~POSNR
VBRP~AUFNR VBRK~MWSBK
INTO CORRESPONDING FIELDS OF TABLE FACTURI
FROM ( VBRP INNER JOIN VBRK
ON VBRP~VBELN = VBRK~VBELN )
WHERE ( VBRK~FKDAT >= PERIOADA-LOW AND VBRK~FKDAT <= PERIOADA-HIGH )
AND VBRP~WERKS = '0100'
AND VBRP~SPART IN DIVIZIA
AND VBRK~KUNAG IN CLIENT
AND VBRP~LGORT IN DEPOZIT
AND VBRP~MATNR IN MATERIAL
AND ( VBRK~FKART LIKE 'F2%' OR
VBRK~FKART LIKE 'L2%' OR
VBRK~FKART LIKE 'G2%' OR
VBRK~FKART LIKE 'RE%' OR
VBRK~FKART LIKE 'S1%' OR
VBRK~FKART LIKE 'S2%' OR
VBRK~FKART LIKE 'ZG2%' OR
VBRK~FKART LIKE 'ZS1%' OR
VBRK~FKART LIKE 'ZS2%' ).

Mai greu e de optimizat o fraza Select pe tabela GLPCA, care la 8 000 000 dureaza peste 5 minute.
Autor:  qntrix [ Mie, 24-Mar-2010 17:43 ]
Subiectul mesajului:  Re:
bogdancioc scrie:
Buna, Mihaela.

Fii fara frica, pune index daca tu crezi ca iti poate mari viteza unei aplicatii. Procesele de business nu vor suferi nici o schimbare din cauza asta.
....

Daca asta e cazul :) , si orisicum, pentru a scapa de frica de care vorbeai, pune acel index. Pe VBRP nu cred sa existe oricum prea multi indecsi in sistemul vostru.


Frumos raspuns. Multumesc si eu.
Pagina 2 din 2 Ora este UTC + 2 [ DST ]
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/