[ORACLE] przyspieszenie selecta z grupowaniem
dap997 - 11-05-2007 12:32
nawiiwan@gazeta.pl wrote:
> On 20 Kwi, 15:23, nawii...@gazeta.pl wrote:
>> Teraz tylko co zrobic z tymi nie znanymi w przyszłości SYS_NR?
>
> Odpowiem wstępnie sam sobie :)
>
> Zrobiłem:
> SELECT s.sys_nr, (SELECT max(step_time) from test_plc
> WHERE test_plc.sys_nr = s.sys_nr) max_step,
> (SELECT sysdate-max(step_time) from test_plc
> WHERE test_plc.sys_nr = s.sys_nr) max_step_diff
> FROM (select distinct(sys_nr) from test_plc) s
> order by max_step desc;
>
> i mam 8s. już nieźle, tylko jak by przyspieszyć to jeszcze trochę :)
Plan i statystyki prosze ;) Z 2-3 krotnym wykonaniem...
dap
nawiiwan@gazeta.pl - 11-05-2007 12:32
On 20 Kwi, 16:50, dap997 <news...@gazeta.pl> wrote:
> nawii...@gazeta.pl wrote:
> > i mam 8s. już nieźle, tylko jak by przyspieszyć to jeszcze trochę :)
>
> Plan i statystyki prosze ;) Z 2-3 krotnym wykonaniem...
:)
teraz nie rozumiem, przed chwilą szło 8s. a teraz idzie 20s.
Plan wykonywania
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=20632 Card=47
Bytes=611)
1 0 SORT (AGGREGATE)
2 1 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
3 2 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
4 0 SORT (AGGREGATE)
5 4 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
6 5 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
7 0 SORT (ORDER BY) (Cost=20632 Card=47 Bytes=611)
8 7 VIEW (Cost=20631 Card=47 Bytes=611)
9 8 HASH (UNIQUE) (Cost=20631 Card=47 Bytes=188)
10 9 INDEX (FAST FULL SCAN) OF 'INDX_TEST_PLC_SYS_NR' (INDEX)
(Cost=17721 Card=39851283 Bytes=159405132)
Statystyki
0 recursive calls
0 db block gets
84698 consistent gets
65479 physical reads
0 redo size
3201 bytes sent via SQL*Net to client
602 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
47 rows processed
dla kilku razy są takie same.
Trochę na nie popatrzyłem i jak rozumiem mój problem polega na
wielkości:
84698 consistent gets
65479 physical reads
Dla tego szybkiego zapytania zaproponowanego przez Lucynę (z dodatkowa
tabelą numery) są dużo mniejsze wartości:
168 consistent gets
8 physical reads
Pozdrawiam,
Maciek
dap997 - 11-05-2007 12:32
nawiiwan@gazeta.pl wrote:
> On 20 Kwi, 16:50, dap997 <news...@gazeta.pl> wrote:
>> nawii...@gazeta.pl wrote:
>>> i mam 8s. już nieźle, tylko jak by przyspieszyć to jeszcze trochę :)
>> Plan i statystyki prosze ;) Z 2-3 krotnym wykonaniem...
>
> :)
> teraz nie rozumiem, przed chwilą szło 8s. a teraz idzie 20s.
> dla kilku razy są takie same.
Sorry, a mogłbyś nic nie wycinać tylko wkleić całość z sqlplusa, dla
tego kilkakrotnego wykonania?
> Trochę na nie popatrzyłem i jak rozumiem mój problem polega na
> wielkości:
> 84698 consistent gets
> 65479 physical reads
Tak wszystko powinno być czytane z cache nie z dysku.
> Dla tego szybkiego zapytania zaproponowanego przez Lucynę (z dodatkowa
> tabelą numery) są dużo mniejsze wartości:
> 168 consistent gets
> 8 physical reads
Hmm i to trwa 8s? a z 65479 physical reads ok 20?
dap
nawiiwan@gazeta.pl - 11-05-2007 12:32
On 20 Kwi, 17:22, dap997 <news...@gazeta.pl> wrote:
> nawii...@gazeta.pl wrote:
> > On 20 Kwi, 16:50, dap997 <news...@gazeta.pl> wrote:
> >> nawii...@gazeta.pl wrote:
> >>> i mam 8s. już nieźle, tylko jak by przyspieszyć to jeszcze trochę :)
> >> Plan i statystyki prosze ;) Z 2-3 krotnym wykonaniem...
>
> > :)
> > teraz nie rozumiem, przed chwilą szło 8s. a teraz idzie 20s.
> > dla kilku razy są takie same.
>
> Sorry, a mogłbyś nic nie wycinać tylko wkleić całość z sqlplusa, dla
> tego kilkakrotnego wykonania?
Oczywiście.
Daję ponizej, wszystko co dał sqlplus, razem z wynikami. Trzy
wykonania.
SYS_NR MAX_STEP MAX_STEP_DIFF
---------- -------- -------------
1 07/04/20 ,003530093
44 07/04/20 ,003553241
43 07/04/20 ,003599537
37 07/04/20 ,003622685
34 07/04/20 ,003645833
32 07/04/20 ,003680556
27 07/04/20 ,003703704
23 07/04/20 ,003726852
22 07/04/20 ,003761574
21 07/04/20 ,003784722
18 07/04/20 ,003842593
17 07/04/20 ,003877315
16 07/04/20 ,003912037
10 07/04/20 ,003946759
8 07/04/20 ,003981481
3 07/04/20 ,00400463
2 07/04/20 ,004027778
36 07/04/20 ,004155093
33 07/04/20 ,004236111
28 07/04/20 ,004282407
20 07/04/20 ,004444444
7 07/04/20 ,00462963
42 07/04/20 ,004756944
30 07/04/20 ,004930556
11 07/04/20 ,005208333
4 07/04/20 ,006111111
41 07/04/20 ,007083333
13 07/04/20 ,007488426
12 07/04/20 ,007511574
9 07/04/20 ,007615741
102 07/04/20 ,010219907
38 07/04/20 ,010497685
29 07/04/20 ,010694444
104 07/04/20 ,011296296
35 07/04/20 ,026898148
31 07/04/20 ,034386574
5 07/04/20 ,042002315
6 07/04/20 ,043831019
103 07/04/20 ,102268519
19 07/04/20 ,139953704
15 07/04/20 ,144490741
14 07/04/20 ,146006944
39 07/04/20 ,169537037
40 07/04/20 ,181678241
26 07/04/19 ,943530093
25 07/04/19 1,21956019
24 07/04/19 1,3443287
47 wierszy zostało wybranych.
Całkowity: 00:00:22.44
Plan wykonywania
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=20632 Card=47
Bytes=611)
1 0 SORT (AGGREGATE)
2 1 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
3 2 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
4 0 SORT (AGGREGATE)
5 4 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
6 5 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
7 0 SORT (ORDER BY) (Cost=20632 Card=47 Bytes=611)
8 7 VIEW (Cost=20631 Card=47 Bytes=611)
9 8 HASH (UNIQUE) (Cost=20631 Card=47 Bytes=188)
10 9 INDEX (FAST FULL SCAN) OF
'INDX_TEST_PLC_SYS_NR' (INDEX) (Cost=17721 Card=39851283
Bytes=159405132)
Statystyki
----------------------------------------------------------
1 recursive calls
0 db block gets
84949 consistent gets
34662 physical reads
232 redo size
3219 bytes sent via SQL*Net to client
602 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
47 rows processed
SYS_NR MAX_STEP MAX_STEP_DIFF
---------- -------- -------------
36 07/04/20 ,000763889
34 07/04/20 ,000787037
32 07/04/20 ,000810185
27 07/04/20 ,000833333
23 07/04/20 ,000856481
21 07/04/20 ,000891204
20 07/04/20 ,000914352
18 07/04/20 ,0009375
17 07/04/20 ,000972222
16 07/04/20 ,001006944
11 07/04/20 ,001053241
10 07/04/20 ,001087963
1 07/04/20 ,001111111
44 07/04/20 ,001134259
43 07/04/20 ,001168981
42 07/04/20 ,001180556
41 07/04/20 ,001215278
38 07/04/20 ,00125
37 07/04/20 ,001273148
33 07/04/20 ,001354167
22 07/04/20 ,002025463
8 07/04/20 ,002210648
3 07/04/20 ,002233796
2 07/04/20 ,002268519
28 07/04/20 ,004988426
7 07/04/20 ,005335648
30 07/04/20 ,005636574
4 07/04/20 ,00681713
13 07/04/20 ,008194444
12 07/04/20 ,008217593
9 07/04/20 ,008321759
102 07/04/20 ,010925926
29 07/04/20 ,011400463
104 07/04/20 ,012002315
35 07/04/20 ,027604167
31 07/04/20 ,035092593
5 07/04/20 ,042708333
6 07/04/20 ,044537037
103 07/04/20 ,102974537
19 07/04/20 ,140659722
15 07/04/20 ,145196759
14 07/04/20 ,146712963
39 07/04/20 ,170243056
40 07/04/20 ,182384259
26 07/04/19 ,944236111
25 07/04/19 1,2202662
24 07/04/19 1,34503472
47 wierszy zostało wybranych.
Całkowity: 00:00:12.43
Plan wykonywania
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=20632 Card=47
Bytes=611)
1 0 SORT (AGGREGATE)
2 1 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
3 2 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
4 0 SORT (AGGREGATE)
5 4 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
6 5 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
7 0 SORT (ORDER BY) (Cost=20632 Card=47 Bytes=611)
8 7 VIEW (Cost=20631 Card=47 Bytes=611)
9 8 HASH (UNIQUE) (Cost=20631 Card=47 Bytes=188)
10 9 INDEX (FAST FULL SCAN) OF
'INDX_TEST_PLC_SYS_NR' (INDEX) (Cost=17721 Card=39851283
Bytes=159405132)
Statystyki
----------------------------------------------------------
0 recursive calls
0 db block gets
84701 consistent gets
2647 physical reads
196 redo size
3184 bytes sent via SQL*Net to client
602 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
47 rows processed
SYS_NR MAX_STEP MAX_STEP_DIFF
---------- -------- -------------
36 07/04/20 ,002106481
34 07/04/20 ,00212963
32 07/04/20 ,002152778
27 07/04/20 ,002175926
23 07/04/20 ,002199074
21 07/04/20 ,002233796
20 07/04/20 ,002256944
18 07/04/20 ,002280093
17 07/04/20 ,002314815
16 07/04/20 ,002349537
11 07/04/20 ,002395833
10 07/04/20 ,002430556
1 07/04/20 ,002453704
44 07/04/20 ,002476852
43 07/04/20 ,002511574
42 07/04/20 ,002523148
41 07/04/20 ,00255787
38 07/04/20 ,002592593
37 07/04/20 ,002615741
33 07/04/20 ,002696759
22 07/04/20 ,003368056
8 07/04/20 ,003553241
3 07/04/20 ,003576389
2 07/04/20 ,003611111
28 07/04/20 ,006331019
7 07/04/20 ,006678241
30 07/04/20 ,006979167
4 07/04/20 ,008159722
13 07/04/20 ,009537037
12 07/04/20 ,009560185
9 07/04/20 ,009664352
102 07/04/20 ,012268519
29 07/04/20 ,012743056
104 07/04/20 ,013344907
35 07/04/20 ,028946759
31 07/04/20 ,036435185
5 07/04/20 ,044050926
6 07/04/20 ,04587963
103 07/04/20 ,10431713
19 07/04/20 ,142002315
15 07/04/20 ,146539352
14 07/04/20 ,148055556
39 07/04/20 ,171585648
40 07/04/20 ,183726852
26 07/04/19 ,945578704
25 07/04/19 1,2216088
24 07/04/19 1,34637731
47 wierszy zostało wybranych.
Całkowity: 00:00:19.38
Plan wykonywania
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=20632 Card=47
Bytes=611)
1 0 SORT (AGGREGATE)
2 1 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
3 2 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
4 0 SORT (AGGREGATE)
5 4 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
6 5 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
7 0 SORT (ORDER BY) (Cost=20632 Card=47 Bytes=611)
8 7 VIEW (Cost=20631 Card=47 Bytes=611)
9 8 HASH (UNIQUE) (Cost=20631 Card=47 Bytes=188)
10 9 INDEX (FAST FULL SCAN) OF
'INDX_TEST_PLC_SYS_NR' (INDEX) (Cost=17721 Card=39851283
Bytes=159405132)
Statystyki
----------------------------------------------------------
0 recursive calls
0 db block gets
84698 consistent gets
1 physical reads
0 redo size
3219 bytes sent via SQL*Net to client
602 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
47 rows processed
SYS_NR MAX_STEP MAX_STEP_DIFF
---------- -------- -------------
36 07/04/20 ,003298611
34 07/04/20 ,003321759
32 07/04/20 ,003344907
27 07/04/20 ,003368056
23 07/04/20 ,003391204
21 07/04/20 ,003425926
20 07/04/20 ,003449074
18 07/04/20 ,003472222
17 07/04/20 ,003506944
16 07/04/20 ,003541667
11 07/04/20 ,003587963
10 07/04/20 ,003622685
1 07/04/20 ,003645833
44 07/04/20 ,003668981
43 07/04/20 ,003703704
42 07/04/20 ,003715278
41 07/04/20 ,00375
38 07/04/20 ,003784722
37 07/04/20 ,00380787
33 07/04/20 ,003888889
22 07/04/20 ,004560185
8 07/04/20 ,00474537
3 07/04/20 ,004768519
2 07/04/20 ,004803241
28 07/04/20 ,007523148
7 07/04/20 ,00787037
30 07/04/20 ,008171296
4 07/04/20 ,009351852
13 07/04/20 ,010729167
12 07/04/20 ,010752315
9 07/04/20 ,010856481
102 07/04/20 ,013460648
29 07/04/20 ,013935185
104 07/04/20 ,014537037
35 07/04/20 ,030138889
31 07/04/20 ,037627315
5 07/04/20 ,045243056
6 07/04/20 ,047071759
103 07/04/20 ,105509259
19 07/04/20 ,143194444
15 07/04/20 ,147731481
14 07/04/20 ,149247685
39 07/04/20 ,172777778
40 07/04/20 ,184918981
26 07/04/19 ,946770833
25 07/04/19 1,22280093
24 07/04/19 1,34756944
47 wierszy zostało wybranych.
Całkowity: 00:00:12.44
Plan wykonywania
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=20632 Card=47
Bytes=611)
1 0 SORT (AGGREGATE)
2 1 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
3 2 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
4 0 SORT (AGGREGATE)
5 4 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
6 5 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
7 0 SORT (ORDER BY) (Cost=20632 Card=47 Bytes=611)
8 7 VIEW (Cost=20631 Card=47 Bytes=611)
9 8 HASH (UNIQUE) (Cost=20631 Card=47 Bytes=188)
10 9 INDEX (FAST FULL SCAN) OF
'INDX_TEST_PLC_SYS_NR' (INDEX) (Cost=17721 Card=39851283
Bytes=159405132)
Statystyki
----------------------------------------------------------
1 recursive calls
0 db block gets
84698 consistent gets
0 physical reads
0 redo size
3201 bytes sent via SQL*Net to client
602 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
47 rows processed
SYS_NR MAX_STEP MAX_STEP_DIFF
---------- -------- -------------
37 07/04/20 ,003032407
43 07/04/20 ,003078704
21 07/04/20 ,003240741
38 07/04/20 ,003275463
33 07/04/20 ,003333333
27 07/04/20 ,003368056
44 07/04/20 ,003402778
32 07/04/20 ,0034375
36 07/04/20 ,003553241
20 07/04/20 ,003576389
17 07/04/20 ,003657407
10 07/04/20 ,00375
34 07/04/20 ,004212963
42 07/04/20 ,004375
16 07/04/20 ,00443287
1 07/04/20 ,004467593
18 07/04/20 ,004722222
11 07/04/20 ,004768519
29 07/04/20 ,005231481
23 07/04/20 ,005289352
41 07/04/20 ,005520833
22 07/04/20 ,007083333
8 07/04/20 ,007268519
3 07/04/20 ,007291667
2 07/04/20 ,007326389
104 07/04/20 ,008321759
102 07/04/20 ,008425926
28 07/04/20 ,010046296
7 07/04/20 ,010393519
30 07/04/20 ,010694444
4 07/04/20 ,011875
13 07/04/20 ,013252315
12 07/04/20 ,013275463
9 07/04/20 ,01337963
35 07/04/20 ,032662037
31 07/04/20 ,040150463
5 07/04/20 ,047766204
6 07/04/20 ,049594907
103 07/04/20 ,108032407
19 07/04/20 ,145717593
15 07/04/20 ,15025463
14 07/04/20 ,151770833
39 07/04/20 ,175300926
40 07/04/20 ,18744213
26 07/04/19 ,949293981
25 07/04/19 1,22532407
24 07/04/19 1,35009259
47 wierszy zostało wybranych.
Całkowity: 00:00:12.43
Plan wykonywania
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=20632 Card=47
Bytes=611)
1 0 SORT (AGGREGATE)
2 1 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
3 2 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
4 0 SORT (AGGREGATE)
5 4 FIRST ROW (Cost=4 Card=847900 Bytes=10174800)
6 5 INDEX (RANGE SCAN (MIN/MAX)) OF
'INDX_TEST_PLC_SYS_NR_STEP_TIME' (INDEX) (Cost=4 Card=847900
Bytes=10174800)
7 0 SORT (ORDER BY) (Cost=20632 Card=47 Bytes=611)
8 7 VIEW (Cost=20631 Card=47 Bytes=611)
9 8 HASH (UNIQUE) (Cost=20631 Card=47 Bytes=188)
10 9 INDEX (FAST FULL SCAN) OF
'INDX_TEST_PLC_SYS_NR' (INDEX) (Cost=17721 Card=39851283
Bytes=159405132)
Statystyki
----------------------------------------------------------
0 recursive calls
0 db block gets
84700 consistent gets
0 physical reads
124 redo size
3149 bytes sent via SQL*Net to client
602 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
47 rows processed
> > Dla tego szybkiego zapytania zaproponowanego przez Lucynę (z dodatkowa
> > tabelą numery) są dużo mniejsze wartości:
> > 168 consistent gets
> > 8 physical reads
>
> Hmm i to trwa 8s? a z 65479 physical reads ok 20?
Nie. To co trwa kilkanaście ms.
Myślałem o zapytaniu Lucyny zmodyfikowanym przeze mnie - dodany
distinct. Teraz ten czas wacha sie od 12 do 22s. - jest w planie i
statystykach powyżej.
Pozdrawiam,
Maciek
Maciej Iwanczewski - 11-05-2007 12:32
nawiiwan@gazeta.pl napisał(a):
>>> Dla tego szybkiego zapytania zaproponowanego przez Lucynę (z dodatkowa
>>> tabelą numery) są dużo mniejsze wartości:
>>> 168 consistent gets
>>> 8 physical reads
>> Hmm i to trwa 8s? a z 65479 physical reads ok 20?
>
> Nie. To co trwa kilkanaście ms.
Przy normalnym czytniku zobaczyłem, że napisałem jakiegoś kwiatka :)
Chodziło mi o to, że powyższy plan dotyczył zapytania zaproponowanego
przez Lucynę, tego z dodatkową tabelą numery i to zapytanie wykonuje się
bardzo szybko - rzędu ms.
Pozdrawiam,
Maciek
Maciej Iwanczewski - 11-05-2007 12:32
nawiiwan@gazeta.pl napisał(a):
> On 20 Kwi, 15:23, nawii...@gazeta.pl wrote:
>> Teraz tylko co zrobic z tymi nie znanymi w przyszłości SYS_NR?
>
> Odpowiem wstępnie sam sobie :)
>
> Zrobiłem:
> SELECT s.sys_nr, (SELECT max(step_time) from test_plc
> WHERE test_plc.sys_nr = s.sys_nr) max_step,
> (SELECT sysdate-max(step_time) from test_plc
> WHERE test_plc.sys_nr = s.sys_nr) max_step_diff
> FROM (select distinct(sys_nr) from test_plc) s
> order by max_step desc;
>
> i mam 8s. już nieźle, tylko jak by przyspieszyć to jeszcze trochę :)
po raz drugi opdowiem sobie :)
Miałem na SYS_NR założony zwykły indeks, usunąłem go i zrobiłem bitmapowy:
CREATE BITMAP INDEX NIDX_TEST_PLC_SYS_NR ON TEST_PLC
(SYS_NR)
i efekt porażający :) Czas rzędu 300ms :)
Pozdrawiam,
Maciek
Maciej Iwanczewski - 11-05-2007 12:32
Maciej Iwanczewski napisał(a):
> Mam w mojej bazie danych taką tabelę:
> CREATE TABLE TEST_PLC
> [...]
> select max(step_time), sysdate-max(step_time), sys_nr from test_plc
> group by sys_nr order by max(step_time) desc
>
> Niestety wykonuje one się dłuugo, około 60 sekund.
To chyba już podsumowanie :)
Jak wspomniałem w innym poście rozwiązaniem okazała się propozycja
Lucyny + mała modyfikacja:
select
(select max(step_time) from test_plc where test_plc.sys_nr = s.sys_nr)
as max_end_time,
(select (sysdate-max(step_time)) from test_plc where test_plc.sys_nr =
s.sys_nr) end_time_diff,
s.sys_nr as sys_nr
from (select distinct(sys_nr) from test_plc) s
order by max_end_time desc
do tego indeksy:
1. na SYS_NR i STEP_TIME
2. bitmapowy na SYS_NR
efekt 300ms :) (więc wcześniej traciliśmy "1900% ciepła" :) )
Dzięki Wam grupowiczki i grupowicze wygląda na to, że problem został
rozwązany. W poniedziałek zrobię testy :)
Dla mnie wnioski z dyskusji są takie, że pownienem poczytać o indeksach,
tuningowaniu bazy, interpretacji planu i statystyki zapytania, tkprof
itp. :)
Trochę tego jest ale się uczę i radochę mi to sprawia, aktualnie
studiuję backup:)
Dziękuję za obfitą i rozwijającą dyskusję :)
Pozdrawiam,
Maciek
=?ISO-8859-2?Q?S=B3awomir_Szysz=B3o?= - 11-05-2007 12:32
Dnia Fri, 20 Apr 2007 20:54:52 +0200, Maciej Iwanczewski
<nawiiwan@wytnij_togazeta.pl> wklepał(-a):
>do tego indeksy:
>1. na SYS_NR i STEP_TIME
>2. bitmapowy na SYS_NR
^^^^^^^^^
Mam nadzieję, że tylko jedna sesja naraz ładuje dane. :)
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych
dap - 11-05-2007 12:32
Maciej Iwanczewski wrote:
> Maciej Iwanczewski napisał(a):
>> Mam w mojej bazie danych taką tabelę:
>> CREATE TABLE TEST_PLC
>> [...]
>> select max(step_time), sysdate-max(step_time), sys_nr from test_plc
>> group by sys_nr order by max(step_time) desc
>>
>> Niestety wykonuje one się dłuugo, około 60 sekund.
>
> To chyba już podsumowanie :)
>
> Jak wspomniałem w innym poście rozwiązaniem okazała się propozycja
> Lucyny + mała modyfikacja:
> select
> (select max(step_time) from test_plc where test_plc.sys_nr = s.sys_nr)
> as max_end_time,
> (select (sysdate-max(step_time)) from test_plc where test_plc.sys_nr =
> s.sys_nr) end_time_diff,
> s.sys_nr as sys_nr
> from (select distinct(sys_nr) from test_plc) s
> order by max_end_time desc
>
> do tego indeksy:
> 1. na SYS_NR i STEP_TIME
> 2. bitmapowy na SYS_NR
>
> efekt 300ms :) (więc wcześniej traciliśmy "1900% ciepła" :) )
>
>
> Dzięki Wam grupowiczki i grupowicze wygląda na to, że problem został
> rozwązany. W poniedziałek zrobię testy :)
Hej,
a mogłbyś wkleićto co zawsze? (autot on) ;)
dap
nawiiwan@gazeta.pl - 11-05-2007 12:32
On 23 Kwi, 07:30, dap <news...@gazeta.pl> wrote:
> a mogłbyś wkleićto co zawsze? (autot on) ;)
jak nie jak tak :)
Dla zapytania:
select
(select max(step_time) from test_plc where test_plc.sys_nr =
s.sys_nr)
as max_end_time,
(select (sysdate-max(step_time)) from test_plc where test_plc.sys_nr
=
s.sys_nr) end_time_diff,
s.sys_nr as sys_nr
from (select distinct(sys_nr) from test_plc) s
order by max_end_time desc
plan:
SELECT STATEMENT ALL_ROWSCost: 6,349 Bytes: 611 Cardinality: 47
CPU Cost: 45,389,121,869
3 SORT AGGREGATE Bytes: 12 Cardinality: 1
2 FIRST ROW Cost: 4 Bytes: 10,174,800 Cardinality: 847,900 CPU
Cost: 28,686
1 INDEX RANGE SCAN (MIN/MAX) INDEX
WABCO.INDX_TEST_PLC_SYS_NR_STEP_TIME Cost: 4 Bytes: 10,174,800
Cardinality: 847,900 CPU Cost: 28,686
6 SORT AGGREGATE Bytes: 12 Cardinality: 1
5 FIRST ROW Cost: 4 Bytes: 10,174,800 Cardinality: 847,900 CPU
Cost: 28,686
4 INDEX RANGE SCAN (MIN/MAX) INDEX
WABCO.INDX_TEST_PLC_SYS_NR_STEP_TIME Cost: 4 Bytes: 10,174,800
Cardinality: 847,900 CPU Cost: 28,686
10 SORT ORDER BY Cost: 6,349 Bytes: 611 Cardinality: 47 CPU Cost:
45,389,121,869
9 VIEW SYSTEM. Cost: 6,348 Bytes: 611 Cardinality: 47 CPU Cost:
45,373,527,317
8 HASH UNIQUE Cost: 6,348 Bytes: 188 Cardinality: 47 CPU Cost:
45,373,527,317
7 BITMAP INDEX FAST FULL SCAN INDEX (BITMAP)
WABCO.NIDX_TEST_PLC_SYS_NR Cost: 3,438 Bytes: 159,405,132
Cardinality: 39,851,283 CPU Cost: 25,387,132
Pozdrawiam,
Maciek
Lucyna Witkowska - 11-05-2007 12:32
nawiiwan@gazeta.pl napisał:
> from (select distinct(sys_nr) from test_plc) s
> plan:
> 7 BITMAP INDEX FAST FULL SCAN INDEX (BITMAP)
> WABCO.NIDX_TEST_PLC_SYS_NR Cost: 3,438 Bytes: 159,405,132
> Cardinality: 39,851,283 CPU Cost: 25,387,132
Jeszcze taka ostatnia uwaga - wczytanie 160MB indeksu troche kosztuje.
Zrobilabym jednak tabelke z sys_nr, ktora wypelnialaby sie automatycznie.
Przy wczytywaniu danych do tabeli glownej trigger sprawdzalby, czy taki
sys_nr juz jest, jesli nie - dodawałby jeden wiersz do tabeli z
numerami.
Przy okazji mogłaby tam byc tez kolumna trzymajac max(daty)
i to byloby jeszcze inne rozwiązanie problemu :-)
Pozdrowienia,
LW
nawiiwan@gazeta.pl - 11-05-2007 12:32
On 23 Kwi, 09:55, Lucyna Witkowska <ypwit...@nospamcyf-kr.edu.pl>
wrote:
> nawii...@gazeta.pl napisał:
>
> > from (select distinct(sys_nr) from test_plc) s
> > plan:
> > 7 BITMAP INDEX FAST FULL SCAN INDEX (BITMAP)
> > WABCO.NIDX_TEST_PLC_SYS_NR Cost: 3,438 Bytes: 159,405,132
> > Cardinality: 39,851,283 CPU Cost: 25,387,132
>
> Jeszcze taka ostatnia uwaga - wczytanie 160MB indeksu troche kosztuje.
> Zrobilabym jednak tabelke z sys_nr, ktora wypelnialaby sie automatycznie.
> Przy wczytywaniu danych do tabeli glownej trigger sprawdzalby, czy taki
> sys_nr juz jest, jesli nie - dodawałby jeden wiersz do tabeli z
> numerami.
> Przy okazji mogłaby tam byc tez kolumna trzymajac max(daty)
> i to byloby jeszcze inne rozwiązanie problemu :-)
Myślisz o mniej więcej tym co ja myślałem (post o godz. 09.00 z
20.04.2007)? :)
A ciekawi mnie z tym kosztem. Dlaczego mimo, że jest to nie mało
danych to zapytanie robi się bardzo szybko. Są to ms (ok 30-40ms). Czy
powinienem rzeczywiście skupic sie na minimalizacji tych 160MB czy
mogę darować sobie jak chodzi szybko?
Pozdrawiam,
Maciek
dap - 11-05-2007 12:32
nawiiwan@gazeta.pl wrote:
> On 23 Kwi, 09:55, Lucyna Witkowska <ypwit...@nospamcyf-kr.edu.pl>
> wrote:
>> nawii...@gazeta.pl napisał:
>>
>>> from (select distinct(sys_nr) from test_plc) s
>>> plan:
>>> 7 BITMAP INDEX FAST FULL SCAN INDEX (BITMAP)
>>> WABCO.NIDX_TEST_PLC_SYS_NR Cost: 3,438 Bytes: 159,405,132
>>> Cardinality: 39,851,283 CPU Cost: 25,387,132
>> Jeszcze taka ostatnia uwaga - wczytanie 160MB indeksu troche kosztuje.
>> Zrobilabym jednak tabelke z sys_nr, ktora wypelnialaby sie automatycznie.
>> Przy wczytywaniu danych do tabeli glownej trigger sprawdzalby, czy taki
>> sys_nr juz jest, jesli nie - dodawałby jeden wiersz do tabeli z
>> numerami.
>> Przy okazji mogłaby tam byc tez kolumna trzymajac max(daty)
>> i to byloby jeszcze inne rozwiązanie problemu :-)
>
> Myślisz o mniej więcej tym co ja myślałem (post o godz. 09.00 z
> 20.04.2007)? :)
>
> A ciekawi mnie z tym kosztem. Dlaczego mimo, że jest to nie mało
> danych to zapytanie robi się bardzo szybko. Są to ms (ok 30-40ms). Czy
> powinienem rzeczywiście skupic sie na minimalizacji tych 160MB czy
> mogę darować sobie jak chodzi szybko?
Hej,
moim zdaniem to w dalszym ciagu nie jest ok :), za duzo odczytów z dysku
no, coś chyba z pamięcią (wielkość obszaru sortowania? przy wielokrotym
wykonaniu czasy są różne) i niewłaściwe użycie indexu bitmap.
Mam kilka propozycji ale niestety nie dam rady ich zrobić na przykladach.
1) Użycie funkcji analitycznych (tak jak to wcześniej próbowałem, ale
coś nie wyszło :))
2) Podział na część starą (starą może być mała tabelka z przeliczonymi
wartoścami) i nowa tak by dostęp był przez union, np:
select max(step_time), sysdate-max(step_time), sys_nr
from test_plc
where step_time > sysdate - 2
group by sys_nr order by max(step_time) desc
union
select max(step_time), sysdate-max(step_time), sys_nr
from test_plc
where sys_nr in (1,2,3,4,5,6,7,....)
group by sys_nr order by max(step_time) desc;
3)
Zrobienie 8 partycji wg. czasu, zmiana parameteru parallel z 1 na 8,
kompresja 7 wczesniejszych partycji (te się nie zmienią)
4) kompresja indeksów i tabeli
dap
Lucyna Witkowska - 11-05-2007 12:32
nawiiwan@gazeta.pl napisał:
> Myślisz o mniej więcej tym co ja myślałem (post o godz. 09.00 z
> 20.04.2007)? :)
Niestety nie moge znalezc tego posta, ale pewnie tak.
> A ciekawi mnie z tym kosztem. Dlaczego mimo, że jest to nie mało
> danych to zapytanie robi się bardzo szybko. Są to ms (ok 30-40ms). Czy
> powinienem rzeczywiście skupic sie na minimalizacji tych 160MB czy
> mogę darować sobie jak chodzi szybko?
Jesli jestes zadowolony i strona odswieża sie szybko - mozesz sobie
darowac :-)
Bądź tylko swiadom kosztów - przyspieszenie obliczen dokonalo sie przez
zajęcie wiekszej pamięci (2 indeksy).
Zastosowany indeks bitmapowy - akurat jak
wykazały zgodnie doswiadczenie i teoria (dane o niskiej selektywnosci) byl
lepszy od B-tree, ale poniewaz jest czytany przez FAST FULL SCAN
szybko wylatuje z pamieci SGA. Dlatego kolejne zapytania musza go ponownie
odczytac i nie dają przyspieszenia.
Pozdrowienia,
Lucyna
Maciej Iwanczewski - 11-05-2007 12:32
Lucyna Witkowska napisał(a):
> nawiiwan@gazeta.pl napisał:
>> Myślisz o mniej więcej tym co ja myślałem (post o godz. 09.00 z
>> 20.04.2007)? :)
>
> Niestety nie moge znalezc tego posta, ale pewnie tak.
To zacytuję siebie :0
"Jeszcze myślałem o zrobieniu triggera na tabeli test_plc który w
dodatkowej tabeli max_time najpierw by usuwał wpis dla insert-owanego
sys_nr i następnie ładował by do niej nowy sys_nr i step_time. mniej
więcej tak:
delete from max_time where sys_nr=xxx
insert into max_time(sys_nr,step_time) values (xxx,zzz)
U mnie jest tak, że każdy następny step_time jest "nowszy" od
poprzedniego ponieważ sa to wyniki z pracy maszyny ściągane z niej po
kolei."
> Jesli jestes zadowolony i strona odswieża sie szybko - mozesz sobie
> darowac :-)
>
> Bądź tylko swiadom kosztów - przyspieszenie obliczen dokonalo sie przez
> [...]
Z tej dużowątkowej dyskusji wynika dla mnie wniosek, że select który
działa to połowa sukcesu. Trzeba jeszcze zwrócić na obciążenie które on
generuje (jezeli oczywiście ma być często uruchamiany).
Na tą chwilę moja wiedza jest uboga, ale trochę poczytam i będę próbował
optymalizować moje select-y.
Pozdrawiam,
Maciek
Maciej Iwanczewski - 11-05-2007 12:32
dap napisał(a):
> moim zdaniem to w dalszym ciagu nie jest ok :), za duzo odczytów z dysku
> no, coś chyba z pamięcią (wielkość obszaru sortowania? przy wielokrotym
> wykonaniu czasy są różne) i niewłaściwe użycie indexu bitmap.
Na tą chwilę praktycznie mogę zostawić to co zrobiliśmy grupowo. Jest to
uruchamiane kilkanaście razy dziennie.
> Mam kilka propozycji ale niestety nie dam rady ich zrobić na przykladach.
To jutro postaram się zapodać export na stronę www, będzie materiał do
ćwiczeń :) Jak tylko będziesz miał ochotę... :)
> 2) Podział na część starą (starą może być mała tabelka z przeliczonymi
> wartoścami) i nowa tak by dostęp był przez union, np:
>
Zamiast tego chyba bym bardziej preferował triggera i dodatkową tabelę.
Ale tego nie testowałem jeszcze.
> 3)
> Zrobienie 8 partycji wg. czasu, zmiana parameteru parallel z 1 na 8,
> kompresja 7 wczesniejszych partycji (te się nie zmienią)
Nie do końca rozumiem. Dlaczego 8 partycji. Możesz rozwinąć myśl.
> 4) kompresja indeksów i tabeli
Jak rozumiem "compress" na końcu. Spróbuję z tym bitmapowym.
Pozdrawiam,
Maciek
Maciej Iwanczewski - 11-05-2007 12:32
Maciej Iwanczewski napisał(a):
> To jutro postaram się zapodać export na stronę www, będzie materiał do
> ćwiczeń :) Jak tylko będziesz miał ochotę... :)
No to exportu nie bedzie... troche duży jest, ok 2GB.
Pozdrawiam,
Maciek
dap - 11-05-2007 12:32
Maciej Iwanczewski wrote:
> Maciej Iwanczewski napisał(a):
>> To jutro postaram się zapodać export na stronę www, będzie materiał do
>> ćwiczeń :) Jak tylko będziesz miał ochotę... :)
>
> No to exportu nie bedzie... troche duży jest, ok 2GB.
Spoko, i tak nie chodzi o posiadanie dokładnie tych samych danych tylko
o popatrzenie na sposób wykonania - a to mogę sobie wygenerować -
problemem jest jak zwykle czas.
dap
dap - 11-05-2007 12:32
Maciej Iwanczewski wrote:
> dap napisał(a):
>> moim zdaniem to w dalszym ciagu nie jest ok :), za duzo odczytów z
>> dysku no, coś chyba z pamięcią (wielkość obszaru sortowania? przy
>> wielokrotym wykonaniu czasy są różne) i niewłaściwe użycie indexu bitmap.
>> 2) Podział na część starą (starą może być mała tabelka z przeliczonymi
>> wartoścami) i nowa tak by dostęp był przez union, np:
>>
>
> Zamiast tego chyba bym bardziej preferował triggera i dodatkową tabelę.
> Ale tego nie testowałem jeszcze.
Tabelke potrzebujesz żeby odczytać te dane które i tak podasz w
nawiasach where, czyli
where id in (,1,1)
robisz
where id in (select id from tabelka_z_id) ;
Przy odczycie z tabelki oracle musi zachować spójność danych, odczytać z
dysku bloczki, itd.
Przy odczycie z danych wpisanych ręcznie, oracle kompiluje to tylko raz
i już zostaje w pamięci.
Oczywiście musi być zagwarantowane, że nie zmienią się żadne id w
przeszłości. Problemem są te nowsze, ale jeśli dodajesz je kolejno to
wpisanie na zapas też powinno być ok :)
>> 3)
>> Zrobienie 8 partycji wg. czasu, zmiana parameteru parallel z 1 na 8,
>> kompresja 7 wczesniejszych partycji (te się nie zmienią)
>
> Nie do końca rozumiem. Dlaczego 8 partycji. Możesz rozwinąć myśl.
Bo masz 8 rdzeni w 2 procesorach.
>> 4) kompresja indeksów i tabeli
Tak.
> Jak rozumiem "compress" na końcu. Spróbuję z tym bitmapowym.
Tak, ale to sprawdza się głownie w indeksach wielokolumnowych.
dap
--
dap.polanski.biz
Maciej Iwanczewski - 11-05-2007 12:32
dap napisał(a):
> Tabelke potrzebujesz żeby odczytać te dane które i tak podasz w
> nawiasach where, czyli
> [...]
Będę kombinował jeszcze z tym zapytaniem w tak zwanej wolnej chwilii :)
Dzięki za podpowiedzi.
Pozdrawiam,
Maciek
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
Strona 2 z 2 • Znaleźliśmy 120 postów • 1, 2
|
Oracle, SQL, PL/SQL. Jak =?ISO-8859-2?Q?napisa=E6_zapytanie=2C?==?ISO-8859-2?Q?_kt=F3re_zwr=F3ci_nazw=EA_atrybutu=2C_kt=F3reg o?==?ISO-8859-2?Q?_warto=B6ci_spe=B3niaj=B1_zadany_warunek?=
Oracle 19g +Insert +Insert +Insert...
[oracle] zapytanie dynamiczne z =?ISO-8859-2?Q?=22dynamiczn=B1_?==?ISO-8859-2?Q?nazw=B1_tabeli=22?=
[Oracle] jak =?ISO-8859-2?Q?ograniczy=E6_pami=EA=E6_dla_se?==?ISO-8859-2?Q?rwera=3F?=
=?ISO-8859-2?Q?=5BOT=5D_Zdany_egzamin_Oracle_1Z0-007_a?==?ISO-8859-2?Q?_brak_informacji_na_stronie_Prometric_-_czy?==?ISO-8859-2?Q?_co=B6_nie_tak=3F?=
[oracle] czy da =?ISO-8859-2?Q?si=EA_z_poziomu_procedury_?==?ISO-8859-2?Q?zrobi=E6_kopi=EA_zapasow=B1=3F?=
[oracle 10g] czy =?ISO-8859-2?Q?mo=BFna_wy=B3=B1czy=E6_wszys?==?ISO-8859-2?Q?tkie_wi=EAzy_w_schemacie=3F?=
MSSQL Express czy Oracle Express
=?iso-8859-2?q?[oracle]_Jak_sprawdzi=E6_wielko=B6=E6_tabeli_=3F=3F?=
=?ISO-8859-2?Q?Poszukjue_ksi=B1=BFki_"Oracle_?= =?ISO-8859-2?Q?optymalizacja_wydajno=B6ci"..?=
zanotowane.pldoc.pisz.plpdf.pisz.pltejsza.htw.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
