powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / UNION ALL: правило старшинства или порядок выполнения
35 сообщений из 35, показаны все 2 страниц
UNION ALL: правило старшинства или порядок выполнения
    #32842677
kdima71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет всем!
Пока новичок в DB2.

Я имею DB2 UDB v.8.2 for Win2000 (после FixPack 7).

Graeme Birchall в книге DB2 UDB V8.2 SQL Cookbook пишет в своих замечаниях к операторам UNION, INTERSECT, and EXCEPT (стр. 245):
Precedence Rules
When multiple operations are done in the same SQL statement, there are precedence rules:
- Operations in parenthesis are done first.
- INTERSECT operations are done before either UNION or EXCEPT.
- Operations of equal worth are done from top to bottom.

( Выделено мною )

Смотрим далее...
IBM в справочнике DB2 Universal Database SQL Reference, Volume 1 version 8.2 в главе 4. Запросы пишет в части Fullselect следующее (стр. 487):
When multiple operations are combined in an expression, operations within parentheses are performed first. If there are no parentheses, the operations are
performed from left to right
with the exception that all INTERSECT operations are performed before UNION or EXCEPT operations.

( Выделено мною )

Я делаю следующее:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
DROP TABLE t1;
DROP TABLE t2;
DROP TABLE t3;
DROP TABLE t4;
DROP TABLE t5;
DROP TABLE t6;
DROP TABLE t7;
DROP TABLE t8;
DROP TABLE t9;

CREATE TABLE t1 (
 DOC_ID         INTEGER     NOT NULL,
 NODE_ID        INTEGER     NOT NULL,
 CONSTRAINT t1_NODE_CHK 
  CHECK (NODE_ID =  1 )
  ENFORCED 
  ENABLE QUERY OPTIMIZATION
);

CREATE TABLE t2 (
 DOC_ID         INTEGER     NOT NULL,
 NODE_ID        INTEGER     NOT NULL,
 CONSTRAINT t2_NODE_CHK 
  CHECK (NODE_ID =  2 )
  ENFORCED 
  ENABLE QUERY OPTIMIZATION
);

CREATE TABLE t3 (
 DOC_ID         INTEGER     NOT NULL,
 NODE_ID        INTEGER     NOT NULL,
 CONSTRAINT t3_NODE_CHK 
  CHECK (NODE_ID =  3 )
  ENFORCED 
  ENABLE QUERY OPTIMIZATION
);

CREATE TABLE t4 (
 DOC_ID         INTEGER     NOT NULL,
 NODE_ID        INTEGER     NOT NULL,
 CONSTRAINT t4_NODE_CHK 
  CHECK (NODE_ID =  4 )
  ENFORCED 
  ENABLE QUERY OPTIMIZATION
);

CREATE TABLE t5 (
 DOC_ID         INTEGER     NOT NULL,
 NODE_ID        INTEGER     NOT NULL,
 CONSTRAINT t5_NODE_CHK 
  CHECK (NODE_ID =  5 )
  ENFORCED 
  ENABLE QUERY OPTIMIZATION
);

CREATE TABLE t6 (
 DOC_ID         INTEGER     NOT NULL,
 NODE_ID        INTEGER     NOT NULL,
 CONSTRAINT t6_NODE_CHK 
  CHECK (NODE_ID =  6 )
  ENFORCED 
  ENABLE QUERY OPTIMIZATION
);

CREATE TABLE t7 (
 DOC_ID         INTEGER     NOT NULL,
 NODE_ID        INTEGER     NOT NULL,
 CONSTRAINT t7_NODE_CHK 
  CHECK (NODE_ID =  7 )
  ENFORCED 
  ENABLE QUERY OPTIMIZATION
);

CREATE TABLE t8 (
 DOC_ID         INTEGER     NOT NULL,
 NODE_ID        INTEGER     NOT NULL,
 CONSTRAINT t8_NODE_CHK 
  CHECK (NODE_ID =  8 )
  ENFORCED 
  ENABLE QUERY OPTIMIZATION
);

CREATE TABLE t9 (
 DOC_ID         INTEGER     NOT NULL,
 NODE_ID        INTEGER     NOT NULL,
 CONSTRAINT t9_NODE_CHK 
  CHECK (NODE_ID =  9 )
  ENFORCED 
  ENABLE QUERY OPTIMIZATION
);

Теперь создаю представление и загружаю данные...

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
CREATE VIEW t_v AS
SELECT * FROM t1 UNION ALL
SELECT * FROM t2 UNION ALL
SELECT * FROM t3 UNION ALL
SELECT * FROM t4 UNION ALL
SELECT * FROM t5 UNION ALL
SELECT * FROM t6 UNION ALL
SELECT * FROM t7 UNION ALL
SELECT * FROM t8 UNION ALL
SELECT * FROM t9;

INSERT INTO T_V (DOC_ID, NODE_ID)
VALUES ( 1 , 1 ),( 1 , 2 ),( 1 , 3 ),( 1 , 4 ),( 1 , 5 ),( 1 , 6 ),( 1 , 7 ),( 1 , 8 ),( 1 , 9 );

COMMIT;


Теперь посмотрим план доступ для следующего запроса:
SELECT * FROM T_V

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
DB2 Universal Database Version  8 . 1 ,  5622 - 044  (c) Copyright IBM Corp.  1991 ,  2002 

Licensed Material - Program Property of IBM

IBM DB2 Universal Database SQL Explain Tool

******************** DYNAMIC ***************************************

==================== STATEMENT ==========================================


	Isolation Level          = Cursor Stability

	Blocking                 = Block Unambiguous Cursors

	Query Optimization Class =  5 

	Partition Parallel       = No

	Intra-Partition Parallel = No

	SQL Path                 = "SYSIBM", "SYSFUN", "SYSPROC", "KDIMA"


SQL Statement:

  SELECT * FROM T_V

Section Code Page =  1251 

Estimated Cost =  96 . 904671 

Estimated Cardinality =  1503 . 000000 

(

|  Access Table Name = KDIMA.T8  ID =  9 , 263 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T7  ID =  9 , 262 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T6  ID =  9 , 261 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T5  ID =  9 , 260 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T4  ID =  9 , 259 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T3  ID =  9 , 258 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T2  ID =  9 , 257 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T1  ID =  9 , 256 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T9  ID =  9 , 264 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

)

Return Data to Application

|  #Columns =  2 

End of section

Optimizer Plan:

                                 RETURN 

                                 (    1 ) 

                                   |    

                                 UNION  

                                 (    2 ) 

   +-------+-------+-------+-------+-------+-------+-------+-------+

 TBSCAN  TBSCAN  TBSCAN  TBSCAN  TBSCAN  TBSCAN  TBSCAN  TBSCAN  TBSCAN 

 (    3 )  (    4 )  (    5 )  (    6 )  (    7 )  (    8 )  (    9 )  (   10 )  (   11 ) 

   |       |       |       |       |       |       |       |       |    

 Table:  Table:  Table:  Table:  Table:  Table:  Table:  Table:  Table: 

 KDIMA   KDIMA   KDIMA   KDIMA   KDIMA   KDIMA   KDIMA   KDIMA   KDIMA  

 T8      T7      T6      T5      T4      T3      T2      T1      T9     

Из плана следует, что DB2 осуществляет доступ к таблицам не в том порядке, в котором таблицы были перечислены в представлении T_V.

Для проверки выполним этот запрос:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
DOC_ID      NODE_ID
----------- -----------
          1           8
          1           7
          1           6
          1           5
          1           4
          1           3
          1           2
          1           1
          1           9

  9 записей выбрано.

Я заключал наборы в скобки и менял класс оптимизации ( dft_queryopt ) и делал многое другое, но это не решило проблемы. Причем самое интересное в том, что при INSERT порядок доступа тот, который я задал при создании представления, а в других операциях (SELECT, INSERT, DELETE) нет.

Я считаю это достаточно неприятной проблемой, которая может в итоге привести к нежелательным последствиям в функционировании приложения!!!

В связи с этим у меня несколько вопросов
1. Такая ситуация существует только в DB2 8.2 (и только у меня) или это было и в ранних версиях? Может кто-нибудь это проверить у себя и поделится здесь?
2. Может кто-нибудь порекомендовать проверенный обход этой проблемы или какое-либо решение?
3. Может кто-нибудь объяснить в чем дело? Или это все-таки "баг"?

Заранее благодарю за любую помощь!

С уважением, kdima71.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32842806
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
As for me, I don't see the relation between precedence rules and access plan.
I would not bind SQL statement precedence to access plan.
I might be wrong.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32843174
Alexander Mozhaev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Теперь посмотрим план доступ для следующего запроса:
SELECT * FROM T_V

У тебя не задан явно порядок сортировки.
поэтому данные будут в том виде в каком их удобно извлечь.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32843225
kdima71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexander MozhaevУ тебя не задан явно порядок сортировки.
поэтому данные будут в том виде в каком их удобно извлечь.
Спасибо за отклик!

Еще раз повторюсь для меня важен соответствующий порядок доступа, а не порядок возвращаемых записей.

Теперь смотрим план для SELECT * FROM T_V ORDER BY NODE_ID...

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
DB2 Universal Database Version  8 . 1 ,  5622 - 044  (c) Copyright IBM Corp.  1991 ,  2002 
Licensed Material - Program Property of IBM
IBM DB2 Universal Database SQL Explain Tool

******************** DYNAMIC ***************************************

==================== STATEMENT ==========================================

	Isolation Level          = Cursor Stability

	Blocking                 = Block Unambiguous Cursors

	Query Optimization Class =  5 

	Partition Parallel       = No

	Intra-Partition Parallel = No

	SQL Path                 = "SYSIBM", "SYSFUN", "SYSPROC", "KDIMA"

SQL Statement:

  SELECT * FROM T_V ORDER BY NODE_ID

Section Code Page =  1251 

Estimated Cost =  95 . 914917 

Estimated Cardinality =  9 . 000000 

(

|  Access Table Name = KDIMA.T8  ID =  9 , 263 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T7  ID =  9 , 262 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T6  ID =  9 , 261 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T5  ID =  9 , 260 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T4  ID =  9 , 259 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T3  ID =  9 , 258 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T2  ID =  9 , 257 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T1  ID =  9 , 256 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

UNION

|  Access Table Name = KDIMA.T9  ID =  9 , 264 

|  |  #Columns =  2 

|  |  Relation Scan

|  |  |  Prefetch: Eligible

|  |  Lock Intents

|  |  |  Table: Intent Share

|  |  |  Row  : Next Key Share

)

Insert Into Sorted Temp Table  ID = t1

|  #Columns =  2 

|  #Sort Key Columns =  1 

|  |  Key  1 : (Ascending)

|  Sortheap Allocation Parameters:

|  |  #Rows     =  9 

|  |  Row Width =  12 

|  Piped

Access Temp Table  ID = t1

|  #Columns =  2 

|  Relation Scan

|  |  Prefetch: Eligible

|  Sargable Predicate(s)

|  |  Return Data to Application

|  |  |  #Columns =  2 

Return Data Completion


End of section

Optimizer Plan:

                                 RETURN 

                                 (    1 ) 

                                   |    

                                 TBSCAN 

                                 (    2 ) 

                                   |    

                                  SORT  

                                 (    3 ) 

                                   |    

                                 UNION  

                                 (    4 ) 

   +-------+-------+-------+-------+-------+-------+-------+-------+

 TBSCAN  TBSCAN  TBSCAN  TBSCAN  TBSCAN  TBSCAN  TBSCAN  TBSCAN  TBSCAN 

 (    5 )  (    6 )  (    7 )  (    8 )  (    9 )  (   10 )  (   11 )  (   12 )  (   13 ) 

   |       |       |       |       |       |       |       |       |    

 Table:  Table:  Table:  Table:  Table:  Table:  Table:  Table:  Table: 

 KDIMA   KDIMA   KDIMA   KDIMA   KDIMA   KDIMA   KDIMA   KDIMA   KDIMA  

 T8      T7      T6      T5      T4      T3      T2      T1      T9     

Порядок доступа не изменился!

P.S. Могли бы Вы реально проверить эту ситуацию у себя и проинформировать эту проверку здесь (OS, версия DB2, план доступа, код и т.д и т.п.). Заранее благодарю!

С уважением, kdima71.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32843291
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще такой вопрос, внутрираздельный параллелизм включен?... Может покапать в этом направлении?
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32843313
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в плане видно что нет...
по большому счету не важно в какой последовательности будут просматриваться таблицы, важно чтобы это проходило параллельно.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32844100
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наводящий вопросы - Почему тебе важен порядок доступа???
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32844209
kdima71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за проявленный интерес к моей проблеме!

Nikolay KulikovНаводящий вопросы - Почему тебе важен порядок доступа??? Чтобы избежать "тупиковую" ситуацию (deadlock)!!!

Теперь позвольте задать свой вопрос - Так так пока никто не поделился со мной информацией, по поводу воспроизведения моей проблемы в своем окружении и не сказал, что у него порядок доступа к таблицам совпадает с порядком, который был определен во время создания представления, то можно ли сделать вывод, что DB2 использует от версии к версии какой-то свой внутренний алгоритм ( неподвластный никому? ) в обработке наборов в UNION ALL и от этого никуда не денешься и с этим надо считаться?

P.S. Повторюсь, я пока новичок в DB2, но имею достаточный опыт в Oracle, чтобы задумываться о проблемах и их решения сейчас, пока я нахожусь в статусе "студента". В скором времени меня ждет настоящая практика...

С уважением, kdima71.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32844283
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
                           RETURN 

                           (    1 ) 

                             |    

                           TBSCAN 

                           (    2 ) 

                             |    

                            SORT  

                           (    3 ) 

                             |    

                           UNION  

                           (    4 ) 

    +---------+---------+----+----+---------+---------+

  TBSCAN    TBSCAN    TBSCAN    TBSCAN    TBSCAN    TBSCAN 

  (    5 )    (    6 )    (    7 )    (    8 )    (    9 )    (   10 ) 

    |         |         |         |         |         |    

 Table:    Table:    Table:    Table:    Table:    Table:   

 DB2ADMIN  DB2ADMIN  DB2ADMIN  DB2ADMIN  DB2ADMIN  DB2ADMIN 

 T5        T4        T3        T2        T1        T6       




Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
                      RETURN 

                      (    1 ) 

                        |    

                      TBSCAN 

                      (    2 ) 

                        |    

                       SORT  

                      (    3 ) 

                        |    

                      UNION  

                      (    4 ) 

    +---------+---------+---------+---------+

  TBSCAN    TBSCAN    TBSCAN    TBSCAN    TBSCAN 

  (    5 )    (    6 )    (    7 )    (    8 )    (    9 ) 

    |         |         |         |         |    

 Table:    Table:    Table:    Table:    Table:   

 DB2ADMIN  DB2ADMIN  DB2ADMIN  DB2ADMIN  DB2ADMIN 

 T4        T3        T2        T1        T5       


T5 T4 T3 T2 T1 T6
T4 T3 T2 T1 T5
- однако закономерность налицо
я полагаю что выборка из TN...T1 должна производиться в параллель, иначе и особого смысла в таком VIEW нет
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32844320
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
  select * 
  from VV 
  where node=? 
  order by node, id

Section Code Page =  1251 

Estimated Cost =  12 , 892182 
Estimated Cardinality =  2 , 342400 

Access Parameterized Table
|  #Columns =  2 
|  Candidate Table # 1 :
|  |  Table Name = DB2ADMIN.T1  ID =  2 , 8 
|  |  Index Scan:  Name = DB2ADMIN.PK  ID =  1 
|  |  |  Regular Index (Not Clustered)
|  |  |  Index Columns:
|  |  |  |   1 : NODE (Ascending)
|  |  |  |   2 : ID (Ascending)
|  Candidate Table # 2 :
|  |  Table Name = DB2ADMIN.T2  ID =  2 , 9 
|  |  Index Scan:  Name = SYSIBM.SQL041224170444650  ID =  1 
|  |  |  Regular Index (Not Clustered)
|  |  |  Index Columns:
|  |  |  |   1 : NODE (Ascending)
|  |  |  |   2 : ID (Ascending)
|  Candidate Table # 3 :
|  |  Table Name = DB2ADMIN.T3  ID =  2 , 10 
|  |  Index Scan:  Name = SYSIBM.SQL041224170444810  ID =  1 
|  |  |  Regular Index (Not Clustered)
|  |  |  Index Columns:
|  |  |  |   1 : NODE (Ascending)
|  |  |  |   2 : ID (Ascending)
|  Candidate Table # 4 :
|  |  Table Name = DB2ADMIN.T4  ID =  2 , 11 
|  |  Index Scan:  Name = SYSIBM.SQL041224170444980  ID =  1 
|  |  |  Regular Index (Not Clustered)
|  |  |  Index Columns:
|  |  |  |   1 : NODE (Ascending)
|  |  |  |   2 : ID (Ascending)
|  Candidate Table # 5 :
|  |  Table Name = DB2ADMIN.T5  ID =  2 , 12 
|  |  Index Scan:  Name = SYSIBM.SQL041224170445150  ID =  1 
|  |  |  Regular Index (Not Clustered)
|  |  |  Index Columns:
|  |  |  |   1 : NODE (Ascending)
|  |  |  |   2 : ID (Ascending)
|  Candidate Table # 6 :
|  |  Table Name = DB2ADMIN.T6  ID =  2 , 13 
|  |  Index Scan:  Name = SYSIBM.SQL041224170445320  ID =  1 
|  |  |  Regular Index (Not Clustered)
|  |  |  Index Columns:
|  |  |  |   1 : NODE (Ascending)
|  |  |  |   2 : ID (Ascending)
|  #Key Columns =  1 
|  |  Start Key: Inclusive Value
|  |  |  |   1 : ?
|  |  Stop Key: Inclusive Value
|  |  |  |   1 : ?
|  Data Prefetch: Eligible  0 
|  Index Prefetch: None
|  Lock Intents
|  |  Table: Intent Share
|  |  Row  : Next Key Share
|  Sargable Predicate(s)
|  |  Return Data to Application
|  |  |  #Columns =  3 
Return Data Completion

End of section


Optimizer Plan:

             RETURN 
             (    1 ) 
               |    
             FETCH  
             (    2 ) 
            /      \
       IXSCAN   Table:   
       (    2 )   DB2ADMIN 
         |      T6       
      Index:   
      DB2ADMIN 
      PK       
         :          
 SYSIBM             
 SQL041224170444650 
         :          
 SYSIBM             
 SQL041224170444810 
         :          
 SYSIBM             
 SQL041224170444980 
         :          
 SYSIBM             
 SQL041224170445150 
         :          
 SYSIBM             
 SQL041224170445320 

...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32844679
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
I did not get _why_ the order of tables in a view has to be the same as in an access plan.
IMHO SQL statement must not have any relations to a way data is accessed.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32846276
kdima71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Большое спасибо всем, кто попытался вместе со мной разобоаться с этой проблемой!

Хочу сразу пояснить, что я не делаю трагедии из этой ситуации, но хочу заметить следующее:

Так как DB2 не может обеспечить порядок доступа к таблицам, как они были перечислены в определении представления, то в случаи одновременного доступа к этим таблицам через такое представление (псевдоразделение данных с помощью UNION ALL), "писателем", который вставляет большое число новых записей (причем записи будут распределяться по нескольки таблицам) и "читателем" (причем запрос будет возвращать данные из нескольких таблиц), возможен deadlock !

Поясню, тупиковая ситуация может произойти, так как при вставке записей, DB2 будет осуществлять доступ к таблицам в том порядке как было определено в представлении, а при запросе будет использоваться совсем другой порядок!

Я считаю, что это очень неприятная проблема (например, в окружении SQL Replication) и непонятно почему IВМ до сих пор не разрешил ее?! Поэтому, буду искать пути решения "походу дела" и заранее благодарю за любые идеи.

С наступающим Новым Годом!
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32846880
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
"Я считаю, что это очень неприятная проблема (например, в окружении SQL Replication) и непонятно почему IВМ до сих пор не разрешил ее?!"
It is not a problem at all.
An SQL statement has nothing to do to a physical access to a data.
It is main principle of RDBMS.
RDBMS can change an access plan with time for the same SQL statement.
You have not relay on the physical access.
The doc does not say DB2 will use the same order in access plane you use in view statement.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32847069
kdima71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggv"It is not a problem at all.

DEADLOCK это не прoблема???
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32847154
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 kdima71
почему вы так уверены что клинч возникнет?... Если вы у читателя поставите уровень изоляции UR то он не возникнет никогда. А чтобы можно было использовать UR - нужно просто правильно проектировать систему.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32847550
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Почему просто не воспользоваться MDC????
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32848209
kdima71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman2 kdima71
почему вы так уверены что клинч возникнет?...

Моя уверенность, основана на том, что я многократно воспроизводил такую ситуацию в своем окружении и могу ее воспроизвести в любой момент для доказательства!!! При необходимости, могу представить здесь свои отчеты!

gardenmanА чтобы можно было использовать UR - нужно просто правильно проектировать систему.

Правильно! Я и пытаюсь, разобраться как нужно оптимально проектировать систему в DB2, которая обеспечивала бы с одной стороны высокий конкурентный доступ, а с другой непротиворечивость данных. Избегая при этом ТУПИКОВЫХ СИТУАЦИЙ. При этом надо учитывать, что будет использоваться SQL Replication. UR - держу в голове, как самый "последний", запасной вариант и возможно будет использоваться только в крайней ситуации.

nkulikovПочему просто не воспользоваться MDC????
Я преследую следующие цели, используя представление с UNION ALL в SQL Replication:
1. Уменьшить взаимное влияние со стороны нескольких источников на целевой массив данных;
2. Горизонтально pазделить целевой массив данных (например по временному диапазону);
3. Обеспечить прозрачность в доступе к одному и тому же массиву данных для "читателя" и "писателя";
4. Обеспечить возможность выполнять различные административные операции по поддержки целевого массива данных в отдельности по разделам;
5. Обеспечить возможность наращивания новых разделов (читай новых источников) без измененения в коде программ.

В текущий момент, разделение данных по разделам с помощью UNION ALL в DB2, это приемлемое на мой взгляд решение, пока не появится разделение на уровне таблиц (partitioning table). Причем UNION ALL обеспечивает любой уровень вложенности (sub-partitioning) и дает возможность разбивать данные используя RANGЕ и LIST методы (в терминологии Oracle).

P.S. Я буду рад, если это поможет в понимании той проблемы, которую я здесь затронул.

С уважением, kdima71.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32848282
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
честно говоря... (не знаю я что у вас за задача) .. но у меня такое ощущение что вы роете не в том направлении...:-(
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32848702
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
looks like db2 ESE with partitioning could help.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32848714
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
unpredictable physical access is not a problem - it is normal for rdbms.
About deadlock and how to workaround - it depends from the system design and described in the doc.
If to use

INSERT INTO T_V (DOC_ID, NODE_ID) VALUES (1,1);
COMMIT;
........................................................................................................................
INSERT INTO T_V (DOC_ID, NODE_ID) VALUES (1,9);
COMMIT;

instead of

INSERT INTO T_V (DOC_ID, NODE_ID)
VALUES (1,1),(1,2),(1,3),(1,4),(1,5),(1,6),(1,7),(1,8),(1,9);
COMMIT;

there is much less posibility for deadlock.
For OLTP do COMMIT as soon as you can in RDBMS based on locking.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32848786
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
I still do not see any relation between the tables order in the access plan and deadlock.
Deadlock is possible regardless _any_ tables order, when more than one transaction accessing rows (row level locking) with different lock and one of them is exclusive.
Deadlock is possible without UNION statement also, and I can create this situation quit easy with two connections only.
And deadlock IS NOT a problem at all.
Even it happened, one transaction will be rolled back with an appropriate error code.
Your applications has to catch the error and repeat the transaction if need.
But read the Concept, DB2 is not Oracle and has to be used differently.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32850609
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Let check the problem with deadlock.
I made a small program fastly.

file insert.c

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int insert (int table, int value);

void usage (char *progname){

fprintf(stderr,
"usage: %s -i <instance> -d <dbname> [ -n amount of insertions, default 1 ]\n",
progname);

}

int main (int argc, char **argv){

int c; /* for getopt and a counter for cycle */
char instance[20] = "";
char dbname[20] = "";
char env[12+20];
int amount = 1;
int f; /* file descriptor */
unsigned short buf;
ssize_t rd;

if(argc < 3) usage(argv[0]), exit(1);

while((c = getopt(argc, argv, "i:d:n:")) != -1){

switch(c){

case 'i':
strncpy(instance, optarg, 20 - 1);
break;

case 'd':
strncpy(dbname, optarg, 20 - 1);
break;

case 'n':
if(!(amount = atoi(optarg))){
fprintf(stderr, "wrong -n argument - '%s'\n", optarg);
usage(argv[0]);
}
break;

default:
usage(argv[0]);
exit(1);
break;

}
}

if(instance[0] == '\0' || dbname[0] == '\0'){

usage(argv[0]);
exit(1);

}

sprintf(env, "DB2INSTANCE=%s", instance);
putenv(env);

f = open("/dev/urandom", O_RDONLY);
if(f == -1){

perror("Could not open /dev/urandom\n");
exit(1);

}

if(connect(dbname)) exit(1);

for(c = 0; c < amount; c++){

rd = read(f, &buf, 2);
if(rd == -1){

perror("Could not read from /dev/urandom\n");
exit(1);

}
if(buf < 0 ) buf *= -1;

printf("%d\n", buf);

/* add here a check for returned value, if it is equal -911
* we got a deadlock or lock timed out,
* we can repeat a transaction */
if (buf >= 0 && buf < 6553) insert (0, buf);
else if (buf >= 6553 && buf < 13106) insert (1, buf);
else if (buf >= 13106 && buf < 19659) insert (2, buf);
else if (buf >= 19659 && buf < 26212) insert (3, buf);
else if (buf >= 26212 && buf < 32765) insert (4, buf);
else if (buf >= 32765 && buf < 39318) insert (5, buf);
else if (buf >= 39318 && buf < 45871) insert (6, buf);
else if (buf >= 45871 && buf < 52424) insert (7, buf);
else if (buf >= 52424 && buf < 58977) insert (8, buf);
else if (buf >= 58977 && buf < 65535) insert (9, buf);

}
}

file tinsert.sqc
#include <stdio.h>
#include <sql.h>
#include <sqlenv.h>
#include <sqlda.h>
#include <sqlca.h>

EXEC SQL INCLUDE SQLCA;

int CHECK_OPER(struct sqlca *ptr, int *sqlcode) {

int rc = 0;
char errMessage[1024];

if (ptr->sqlcode == 0 || ptr->sqlcode == 100 )
return 0;
else{
if(ptr->sqlcode < 0){
strcpy(errMessage, "Error message: ");
}else
strcpy(errMessage, "Warning message: ");
fprintf(stderr, errMessage);
sprintf(errMessage, "SQLCODE = %ld\n", ptr->sqlcode);
}

fprintf(stderr, "got %s\n", errMessage);

rc = sqlaintp( errMessage, 1024, 80, ptr);
fprintf(stderr, "rc %d\n", rc);
if(rc > 0)
fprintf(stderr, "got %s\n", errMessage);

rc = sqlogstt( errMessage, 1024, 80, ptr->sqlstate);
fprintf(stderr, "rc %d\n", rc);
if(rc > 0)
fprintf(stderr, "got %s", errMessage);


if(ptr->sqlcode < 0){
return 1;
}else
return 0;


}

int connect (char *dbname){

int sqlcode;
EXEC SQL BEGIN DECLARE SECTION;
char dbAlias[20];
EXEC SQL END DECLARE SECTION;

strncpy(dbAlias, dbname, 20 - 1);

EXEC SQL CONNECT TO :dbAlias;

if (CHECK_OPER(&sqlca, &sqlcode)) return 1;

return 0;

}

int insert( short table, short value ){

int sqlcode;

EXEC SQL BEGIN DECLARE SECTION;
short doc_id;
short node_id;
EXEC SQL END DECLARE SECTION;

doc_id = value;
node_id = table;

EXEC SQL insert into t_v (doc_id, node_id) values(:doc_id, :node_id);
if (CHECK_OPER(&sqlca, &sqlcode)){

EXEC SQL ROLLBACK;
return sqlcode;

}
EXEC SQL COMMIT;


return 0;

}
Here is a db schema:
#!/bin/sh
. /export/home/db2inst1/sqllib/db2profile

db2 connect to test;

for i in 0 1 2 3 4 5 6 7 8 9
do

echo $i
db2 CREATE TABLE t$i \( \
DOC_ID SMALLINT NOT NULL,\
NODE_ID SMALLINT NOT NULL,\
T TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, \
CONSTRAINT t1_NODE_CHK \
CHECK \(NODE_ID = $i\)\
ENFORCED \
ENABLE QUERY OPTIMIZATION\
\);

db2 -v create index idx_${i}t on t$i \(T\) allow reverse scans;

done

db2 CREATE VIEW t_v AS \
SELECT \* FROM t0 UNION ALL \
SELECT \* FROM t1 UNION ALL \
SELECT \* FROM t2 UNION ALL \
SELECT \* FROM t3 UNION ALL \
SELECT \* FROM t4 UNION ALL \
SELECT \* FROM t5 UNION ALL \
SELECT \* FROM t6 UNION ALL \
SELECT \* FROM t7 UNION ALL \
SELECT \* FROM t8 UNION ALL \
SELECT \* FROM t9;

Let now make a test. A test box is an old one, 1996 year production, 2x300MHz.
time ./insert -i db2inst1 -d test -n 10000

real 1m26.775s
user 0m1.610s
sys 0m1.170s

we have about 116 transactions per second.

in anothe xterm let run db2 "select count(*), node_id from t_v group by node_id"
in a while(1) cycle, and again start
time ./insert -i db2inst1 -d test -n 10000 > /dev/null 2>&1

real 1m29.503s
user 0m1.390s
sys 0m0.690s

so we got about 112 transaction per second and no one deadlock.
It's not good.
Ok, let start a second
time ./insert -i db2inst1 -d test -n 10000
Now we have two clients doing insertion non-stop, ASAP.
Let get some stat at the same time by running
db2 "select sum(doc_id) from t_v where t >= (current_time - 30 seconds)"
We have now three clients, two doing insertion, one doing select, all three works asap and non-stop,
and no any errors nor deadlock.
Let try nselect sum(doc_id) from t_v - the result is the same.

Ok, let try select doc_id, node_id from t_v where t >= (current_timestamp - 1 second)
in another words get all rows last second inserted.
Again there is no deadlock - it just works. I have seen about 270 rows fetched (it's about transactions
per second from both clients doing insertion).
The same result is if we run
db2 update t_v set doc_id=doc_id+1 where doc_id!=9 and t>=(current_timestamp -1 second)
Unfortunatelly, I could not get a deadlock, having four clients working simultaneously.
The final test:
first client doing select for rows inserted in the last second in cycle without interval;
second client doing update doc_id for rows inserted in the last second in cycle again;
third and fourth doing insert ASAP continuosly;

For such old box, with everything are placed on a single hard disk, probably it is not bad.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32858865
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нет, проблемка-то любопытная. Пусть транзакция Tr1 выполняет

select * from t_v where...

а транзакция Tr2 в это же время выполняет

update t_v set ...

при этом подмножества "вовлеченных" записей в Tr1 и Tr2 имеют непустое пересечение.

Если t_v - это таблица, а Tr1 и Tr2 производят сканирование в разных направлениях, то в случае DB2 одна из транзакций может "подвиснуть" на блокировке (до тех пор, пока другая транзакция не завершится). К примеру, Tr1 пытается читать запись, измененную Tr2. Или (уровень изоляции Tr1 выше CS) Tr2 пытается изменить запись, прочитанную Tr1.

Это - привычное дело. А вот когда t_v - это view с UNION ALL, дела обстоят сложнее. Что, если Tr1 читает сперва T1, затем T9, а T2 меняет сперва T9, затем T1? При этом уровень изоляции Tr1 выше CS (ну, или она тоже производит UPDATE)? Это - deadlock.

Требуется доказать, что такого быть не может.

Мне кажется, что этого действительно не может быть - план все время показывает порядок Tn-1..T1, Tn, что должно быть достаточно для предотвращения указанного мной случая.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32860115
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
"А вот когда t_v - это view с UNION ALL, дела обстоят сложнее. Что, если Tr1 читает сперва T1, затем T9, а T2 меняет сперва T9, затем T1? При этом уровень изоляции Tr1 выше CS (ну, или она тоже производит UPDATE)? Это - deadlock."

I might be wrong, but deadlock it is when Tr1 reads T1 then updates T9 and Tr2 reads T9 then updates T1, isn't it?
Both transactions hold a resource and wait for a resource other holds.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32860174
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На уровнях изоляции, больших CS, остается блокировка после чтения (на строке; возможна эскалация на уровень таблицы). Пусть Tr1 в интервал времени Ti1 пытается прочитать строку t1 из таблицы T1, затем в интервал времени Ti2 строку t9 из таблицы T9, а Tr2 пытается в интервал времени Ti1 обновить t9 из T9, затем в интервал времени Ti2 строку t1 из T1.

В интервал времени Ti2
транзакция Tr1 держит блокировку на t1 и не может прочитать t9
транзакция Tr2 держит блокировку на t9 и не может изменить t1 (хотя может читать)

Надо посмотреть по шагам (через Spotlight от Quest Central, к примеру; все никак не соберусь) - когда происходит работа со view наподобие t_v, когда накладываются блокировки типа "intent" на таблицы - сразу после начала запроса или непосредственно при обращении к таблице? Если первое, то, наверное, уже тем самым мы от deadlock'а гарантированы. Если второе, то тогда надо надеяться на оптимизатор. Хотя как вам случай

create view t_v1 as
select * from t1
union all
...
union all
select * from t9


create view t_v2 as
select * from t9
union all
...
union all
select * from t1

?
Впрочем, кем надо быть, чтобы в своей программе сотворить такое? ;-)
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32860285
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
по-моему все кто занимался Ораклом просто-напросто с детству запуганы Томом Кайтом и грязным чтением...((
Я вообще не понимаю каков смысл получать long-running report по данным, которые в настоящий момент меняются? Ведь если запустить такой отчет сразу же после первого выполнения - вся картина все равно поменяется. А в основном все длинные отчеты получаются из уже закомиченных данных. А в этом случае - что грязное чтение, что serialazible - один и тот же результат будет.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32860289
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Nothing to say. I may repeat only I could not get a deadlock in my example.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32860366
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanпо-моему все кто занимался Ораклом просто-напросто с детству запуганы Томом Кайтом и грязным чтением...((
Я вообще не понимаю каков смысл получать long-running report по данным, которые в настоящий момент меняются? Ведь если запустить такой отчет сразу же после первого выполнения - вся картина все равно поменяется.


Ну вообще-то нет. Или - смотря что называть "картиной". Если "картина"="результат запроса", то на serialazible она не должна поменяться (в той же транзакции). Правда, не знаю, сколько в этом пользы.

А в основном все длинные отчеты получаются из уже закомиченных данных. А в этом случае - что грязное чтение, что serialazible - один и тот же результат будет.

Да, у нас тоже так. А можно вообще (постулировать|разработывать модели, требующие), что данные нельзя UPDATE/DELETE, а можно только INSERT, и строить отчеты на записях с TIMESTAMP'ом не выше некоего заданного (скажем, на начало построения отчета).
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32860878
kdima71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanпо-моему все кто занимался Ораклом просто-напросто с детству запуганы Томом Кайтом и грязным чтением...

Уважаемый, пожалуйста, посоветуйте какую-нибудь литературу, чтобы "не бояться" грязного чтения! Буду Вам при много благодарен!
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32862170
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, вот в паре наших баз сперва добавляются данные, затем строятся отчеты (добавляются за январь, считаются за декабрь). Потому уровень изоляции можно ставить какой угодно. В append only базе вместо январь/декабрь может быть сейчас/минутуназад - принцип тот же.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32862368
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Viktor: not always possible to have a database add-only.
We have a VoIP billing system where the info about each call depends from the several packet from several VoIP gateways. Each packet from gateways kept in one table, and the info about calls calculated on the fly and inserted/updated in another table with each coming packet (through MQ queue).
But there are two things:
1) the table with packets from the gateway is add-only and it's absolutely safe to use UR to it because if a packet is in the queue it will be inserted.
2) For hourly/daily/weekly/monthly reports based on calls table we are not interesting in last second/minute/hour/day

Actualy we could reach a huge throughput without deadlocks having a lot of insert/update/select after we got a business logic and made a proper design.
It might be the answer to kdima71 - your business logic only may help you to understand when/where you may use UR.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32878012
Lana Zapornikova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А не сталкивался ли кто со следующей проблемой с грязным чтением:

есть активно (порядка сотен транзакций в минуту) пополняемая табличка (appendOnly). На ней есть несколько индексов типа номер счета + что-то еще, то есть активно модифицируемые по всему объему.

Если запрос из приложения имеет план исполнения, использующий 2 индекса для отбора данных, то он с заметной вероятностью (до 30-50%) падает с ошибкой Invalid cursor state. Поборолось это шаманскими плясками так, чтобы план исполнения использовал только один индекс.

Интересно 1) можно ли с этим бороться более регулярными методами? (Перевести репортинг с UR невозможно)
2)вообще, у кого был опыт с подобным безобразием?

Db2 8.1.6, Windows 2003
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32878232
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
that sounds strange.
I had a system with much more than 100 transactions per second, and a table with SELECT/INSERT/UPDATE, and more then 2 indexes, and different queries with accesing several indexes.
Never got invalid cursor state.
db2 v 8.1.4
Looks like a bug if it is truth. Or something other goes wrong.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32878420
kdima71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Lana Zapornikova...(Перевести репортинг с UR невозможно)

Здравствуйте Lana!

Меня заинтересовала Ваша проблема!

1. Мне интересно знать, только при уровне изоляции UR происходит эта ошибка?
2. Могли бы Вы объяснить причину, невозможности использования в вашей системе отчетов другого уровне изоляции, отличного от UR?
3. Могли бы Вы привести более подробный отчет о вашей проблеме и способы, которые вы использовали для её решения?

Заранее благодарю за ответы!

С уважением kdima71.
...
Рейтинг: 0 / 0
UNION ALL: правило старшинства или порядок выполнения
    #32878597
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Lana
А курсор открывается с опцией WITH HOLD?
...
Рейтинг: 0 / 0
35 сообщений из 35, показаны все 2 страниц
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / UNION ALL: правило старшинства или порядок выполнения
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]