powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Разбивка таблицы на разделы.
25 сообщений из 36, страница 1 из 2
Разбивка таблицы на разделы.
    #32259790
AlexS9
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Позволяет ли DB2 7.2 разбить большую таблицу на разделы и как это сделать?
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32260191
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
О каких, собственно, разделах идет речь? Мне идет на ум две вещи:

1) DB2 EEE (теперь, в v8 - ESE), кластер shared nothing. Определяется partitioning key, по хеш-значению от него данные попадают на тот или иной узел распределенной по серверам базы.
2) Многомерная кластеризация - но это только в v8.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32260463
IBMer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
На самом деле есть еще INSERT в UNION ALL View.

Некая форма Range Partitioning.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32260807
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, это снова в восьмерке (причем появляется с каким-то фикспаком?).
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32260894
AlexS9
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Под разбивкой я подразумевал следующее.
В Оракле с 8 версии существует возможность создания отдельных физических мест хранения данных при едином их логическом имени. Т.е. можно разбить таблицу с 10 млн. записей на 5 таблиц по 2 млн., что существенно увеличит производительность. При этом логически считается, что это одна таблица, а запросы оптимизируются самим Ораклом. То же самое можно сделать и в MS SQL. Там есть возможность создавать горизонтально секцированные представления. Что по сути преследует ту же цель, но решается по другому. Есть ли что-то подобное в DB2 (я думаю, что есть) ? А если нет, то как такая задача решается средствами DB2 ?
Заранее спасибо за все ответы.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32261260
IBMer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Range Partitionin table в DB2 UDB нет в DB2/390 есть. Сколько у тебя записей в таблице что бы начинать обэтом думать, может сначала все таки над plaement поработать???? Опять же есть INSERT во VIEW c UNION ALL.
Когда запись вставляет и определяется в какую таблиц она должна попасть.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32261377
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, я подозревал что-то подобное, но для 7-ки - никак (если не вспоминать про DB2 EEE), кроме как ручным способом (самостоятельно создать таблицы и модифицировать приложение так, чтобы оно вставляло и выбирало, куда вставлять, само или через SP в нужную). Для моих приложений, кстати, достаточно простого reorg'а с нужной упорядоченностью по ночам и index only access.

Многомерная кластеризация (для впихивания целого диапазона - generated поле, которое этому диапазону сопоставляет единичное значение), вставлябельное view с Union all и триггеры INSTEAD - в восьмерке (бр-р-р, память слабая, может, INSTEAD уже в 7.2 были? вряд ли).
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32261403
AlexS9
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
У меня таблица, в которую добавляются данные и никогда не будут удалятся.
Таблица увеличивается на 5 млн. записей ежегодно. При этом старые данные также могут понадобиться. :(((
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32261419
IBMer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Виктор,
INSERT в UNION ALL view работает не как Instead of trigger. Там используется некоторый dynamic dispatch. Это фича 8-ки

Кстати помоему UPDATE and DELETE на UNION ALL view были в 7-ке.

Так же в 8-ке появились многомерные индексы и INSTEAD OF триггеры.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32262275
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я отлично знаю, что INSERT на VIEW с UNION ALL работает не так, как с триггерами INSTEAD, но и тем, и другим можно добиться желаемого результата - вставку записи в одну и только одну таблицу, выбранную по какому-то условию.

Что касается DELETE и UPDATE, это, по-моему, еще во второй версии DB2 /Common Server работало, а может, и в первой.

Сейчас придумал, кстати, решение для 7.2 "через задницу" - вставка в обычную таблицу, где триггер AFTER INSERT вставляет данные в выбранную другую таблицу, а затем немедленно удаляет из своей.

Для данных APPEND ONLY естественнее и удобнее пользоваться MDC (многомерной кластеризацией).

Однако я не уверен в необходимости (полезность - да, а необходимость - нет) всего этого; подумаешь, пять лимонов в год ;-), да здравствует index only access.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32262374
AlexS9
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В документации по поводу INSERT во VIEW c UNION ALL сказано следующее:

1)Для производных таблиц объединения с несколькими псевдонимами в условии FROM разрешено только чтение.
2) Для производных таблицы объединения с одним псевдонимом в условии FROM может быть разрешена и запись.

Но остался один не решенный вопрос.
Если у меня данные в таблице сгрупированы по какому-то признаку, например по времени. Будет ли DB2 просматривать характеристики всех таблиц, входящих в представдение на предмет того, что записи, удовлетворяющие условию оборота WHERE, могут находится только в одной таблице? Т.к. смысла просматривать остальные нет.

Пример:
SELECT * FROM TRADERS WHERE TRADEDATE BETWEEN '1/9/2001' AND '1/10/2001'

Все записи, удовлетворяющие WHERE находятся в таблице TRADE_010901. Было бы хорошо, что бы ядро запросило только эту таблицу, не затрагивая остальных, входящих в представление. Это бы увеличило скорость обработки запроса. Умеет ли это DB2?
Если нет, то INSERT во VIEW c UNION ALL не рашает проблемы.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32262408
IBMer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
AlexS9

А слабо попробовать??? Конечно распараллелит.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32262515
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хм. Очень уж оптимистично. Для начала, я не понял, чью документацию процитировал AlexS9, ибо непонятно, что есть "запись" ("разрешена и запись"), ибо речь могла идти и об INSERT, и об UPDATE (да и весь отрывок совершенно непонятен; уж лучше бы он читал и цитировал английский оригинал). Далее, запросы с BETWEEN нередко тяжело оптимизировать. Вот если бы было поле

ymTRADEDATE integer not null generated as (year(tradedate)*100+month(tradedate))

и вместо

TRADEDATE BETWEEN '1/9/2001' AND '30/09/2001' (скорее всего именно это имелось в виду, а вовсе не TRADEDATE BETWEEN '1/9/2001' AND '1/10/2001' )

было бы

ymTRADEDATE = 200109

то я был бы более спокоен - некоторый толк был бы и для старых версий DB2, а не только 8-ки. Догадается ли оптимизатор 8-ки, что если
в TRADE_200108 стоит constraint(TRADEDATE BETWEEN '1/8/2001' AND '30/08/2001'),
в TRADE_200109 стоит constraint(TRADEDATE BETWEEN '1/9/2001' AND '30/09/2001'),
а в TRADE_200110 имеется constraint (TRADEDATE BETWEEN '1/10/2001' AND '31/10/2001'),
то при WHERE TRADEDATE BETWEEN '20/8/2001' AND '10/09/2001'
надо запрашивать только первые две? Лично я как-то сомневаюсь. Все это надо проверять экспериментально...
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32262568
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Проверяем.
Код: 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.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
create table xxx_200101(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200101 check(td between '2001-01-01' and '2001-01-31'),
  constraint p200101 primary key(id));

create table xxx_200102(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200102 check(td between '2001-02-01' and '2001-02-28'),
  constraint p200102 primary key(id));

create table xxx_200103(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200103 check(td between '2001-03-01' and '2001-03-31'),
  constraint p200103 primary key(id));

create table xxx_200104(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200104 check(td between '2001-04-01' and '2001-04-30'),
  constraint p200104 primary key(id));

create table xxx_200105(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200105 check(td between '2001-05-01' and '2001-05-31'),
  constraint p200105 primary key(id));

create table xxx_200106(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200106 check(td between '2001-06-01' and '2001-06-30'),
  constraint p200106 primary key(id));

create table xxx_200107(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200107 check(td between '2001-07-01' and '2001-07-31'),
  constraint p200107 primary key(id));

create table xxx_200108(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200108 check(td between '2001-08-01' and '2001-08-31'),
  constraint p200108 primary key(id));

create table xxx_200109(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200109 check(td between '2001-09-01' and '2001-09-30'),
  constraint p200109 primary key(id));

create table xxx_200110(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200110 check(td between '2001-10-01' and '2001-10-31'),
  constraint p200110 primary key(id));

create table xxx_200111(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200111 check(td between '2001-11-01' and '2001-11-30'),
  constraint p200111 primary key(id));

create table xxx_200112(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200112 check(td between '2001-12-01' and '2001-12-31'),
  constraint p200112 primary key(id));

create table xxx_200201(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200201 check(td between '2002-01-01' and '2002-01-31'),
  constraint p200201 primary key(id));

create table xxx_200202(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200202 check(td between '2002-02-01' and '2002-02-28'),
  constraint p200202 primary key(id));

create table xxx_200203(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200203 check(td between '2002-03-01' and '2002-03-31'),
  constraint p200203 primary key(id));

create table xxx_200204(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200204 check(td between '2002-04-01' and '2002-04-30'),
  constraint p200204 primary key(id));

create table xxx_200205(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200205 check(td between '2002-05-01' and '2002-05-31'),
  constraint p200205 primary key(id));

create table xxx_200206(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200206 check(td between '2002-06-01' and '2002-06-30'),
  constraint p200206 primary key(id));

create table xxx_200207(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200207 check(td between '2002-07-01' and '2002-07-31'),
  constraint p200207 primary key(id));

create table xxx_200208(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200208 check(td between '2002-08-01' and '2002-08-31'),
  constraint p200208 primary key(id));

create table xxx_200209(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200209 check(td between '2002-09-01' and '2002-09-30'),
  constraint p200209 primary key(id));

create table xxx_200210(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200210 check(td between '2002-10-01' and '2002-10-31'),
  constraint p200210 primary key(id));

create table xxx_200211(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200211 check(td between '2002-11-01' and '2002-11-30'),
  constraint p200211 primary key(id));

create table xxx_200212(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200212 check(td between '2002-12-01' and '2002-12-31'),
  constraint p200212 primary key(id));

create table xxx_200301(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200301 check(td between '2003-01-01' and '2003-01-31'),
  constraint p200301 primary key(id));

create table xxx_200302(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200302 check(td between '2003-02-01' and '2003-02-28'),
  constraint p200302 primary key(id));

create table xxx_200303(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200303 check(td between '2003-03-01' and '2003-03-31'),
  constraint p200303 primary key(id));

create table xxx_200304(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200304 check(td between '2003-04-01' and '2003-04-30'),
  constraint p200304 primary key(id));

create table xxx_200305(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200305 check(td between '2003-05-01' and '2003-05-31'),
  constraint p200305 primary key(id));

create table xxx_200306(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200306 check(td between '2003-06-01' and '2003-06-30'),
  constraint p200306 primary key(id));

create table xxx_200307(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200307 check(td between '2003-07-01' and '2003-07-31'),
  constraint p200307 primary key(id));

create table xxx_200308(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200308 check(td between '2003-08-01' and '2003-08-31'),
  constraint p200308 primary key(id));

create table xxx_200309(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200309 check(td between '2003-09-01' and '2003-09-30'),
  constraint p200309 primary key(id));

create table xxx_200310(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200310 check(td between '2003-10-01' and '2003-10-31'),
  constraint p200310 primary key(id));

create table xxx_200311(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200311 check(td between '2003-11-01' and '2003-11-30'),
  constraint p200311 primary key(id));

create table xxx_200312(
  id integer not null generated by default as identity,
  td date not null,
  constraint c200312 check(td between '2003-12-01' and '2003-12-31'),
  constraint p200312 primary key(id));

create view xxx(td,id) as 
select td, id from xxx_200101
UNION ALL
select td, id from xxx_200102
UNION ALL
select td, id from xxx_200103
UNION ALL
select td, id from xxx_200104
UNION ALL
select td, id from xxx_200105
UNION ALL
select td, id from xxx_200106
UNION ALL
select td, id from xxx_200107
UNION ALL
select td, id from xxx_200108
UNION ALL
select td, id from xxx_200109
UNION ALL
select td, id from xxx_200110
UNION ALL
select td, id from xxx_200111
UNION ALL
select td, id from xxx_200112
UNION ALL
select td, id from xxx_200201
UNION ALL
select td, id from xxx_200202
UNION ALL
select td, id from xxx_200203
UNION ALL
select td, id from xxx_200204
UNION ALL
select td, id from xxx_200205
UNION ALL
select td, id from xxx_200206
UNION ALL
select td, id from xxx_200207
UNION ALL
select td, id from xxx_200208
UNION ALL
select td, id from xxx_200209
UNION ALL
select td, id from xxx_200210
UNION ALL
select td, id from xxx_200211
UNION ALL
select td, id from xxx_200212
UNION ALL
select td, id from xxx_200301
UNION ALL
select td, id from xxx_200302
UNION ALL
select td, id from xxx_200303
UNION ALL
select td, id from xxx_200304
UNION ALL
select td, id from xxx_200305
UNION ALL
select td, id from xxx_200306
UNION ALL
select td, id from xxx_200307
UNION ALL
select td, id from xxx_200308
UNION ALL
select td, id from xxx_200309
UNION ALL
select td, id from xxx_200310
UNION ALL
select td, id from xxx_200311
UNION ALL
select td, id from xxx_200312
;
insert into xxx(td) values(current date);

select * from xxx where td between '2001-03-07' and '2001-05-05'
;
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32262583
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Оптимизированный план доступа" для

select * from xxx where td between '2001-03-07' and '2001-05-05'

в DB2 8.1.3

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SELECT Q7.$C0 AS  "TD" , Q7.$C1 AS  "ID"  
FROM (SELECT Q1. "TD" , Q1. "ID"  
            FROM VVM.XXX_200103 AS Q1 
          WHERE (Q1. "TD"  <= '2001-05-05') AND ('2001-03-07' <=  Q1. "TD" ) 
UNION ALL 
SELECT Q3. "TD" , Q3. "ID"  
FROM VVM.XXX_200104 AS Q3 
WHERE (Q3. "TD"  <= '2001-05-05') AND ('2001-03-07' <=  Q3. "TD" ) 
UNION ALL 
SELECT Q5. "TD" , Q5. "ID"  
FROM VVM.XXX_200105 AS Q5 
WHERE (Q5. "TD"  <= '2001-05-05') AND ('2001-03-07' <=  Q5. "TD" ) ) AS Q7 


Как видим, все хорошо. Интересно, что получится в 7-ке.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32328039
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Можно ли поднять тему опять?
Такое вот разбиение делаеться для повышения производительности путем снижения I/O.
Ну по поводу MDC и view with UNION ALL уже сказали (возможно последнее добавилось в V7.x при fixpack?)
А вот что по поводу разбиения таблицы по контейнерам? конечно же, это ни в коей мере не то же, что и первые два "путя", но всё таки?
Создание таблицы с индексами на отдельном tablespape из нескольких контейнеров, самой таблицы на другой tablespace из нескольких контейнеров, с обязательным условием чтобы ни доступ к tablespace'ам не пересекался, ни доступ к контейнерам внетри tablespace. Ну там разные диски, разные контроллеры. Индексы - на один контроллер, данные - на другой, и контейнеры по дискам.
Таким путем можно здорово сократить I/O....
?
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32328399
IBMer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ну это само собой разумеещееся. Положить табличные TBSP, индексные TBSP и журналы транзакций в на разные диски контроллеры. Опять же стоит учитывать размеры extent'ов, prefetch size.

Например не правильно сконфигурировав extents, prefetch size очень легко просадить Shark. Все очень сильно зависит от конфигурации дисковой подсистемы

Но одно правило можно наверно всегда надо учитывать. Большие таблицы имеет смысл класть в отдельные TBSP от мелких и назначать разные буфферные пулы. Если все будет лежать в одной куче то страницы мелких таблиц будут постоянно вымываться из буфферпула и следовательно постоянно будет наличие direct io что не есть good.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32328434
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Кстати. раз уж extents & prefetch size затронули - где бы почитать про искусство их выбора? Я что-то конкретно таких рекомендаций и не помню.
А ведь действительно - важнейшие параметры.
Ну про bufferpools - так их НЕиспользование пожалуй надо считать дурным тоном :)
Уж коли дадена такая возможность, то упускать ее :)
Помню, когда sybase воплотил named pools, то стоко радости было :)
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32331322
IBMer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Нашел заметки после одного из проектов (это правда про Shark, но для других систем тоже самое)
Adjust Extent Size to ESS stripe size
1) ESS stripe granularity is 32 KB (6 x 32 = 192)
2) Selecting a multiple of 32 KB makes sure that multiple ESS disks are used within a rank for DB2 big block I/O/prefetch
3) If Extent Size is less than the full array width, ESS sequential prefetch might kick in to keep all disks busy
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32331387
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Нельзя ли расшифровать акроним ESS ?
Спасибо.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32331490
IBMer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Enterprise Storage Server. Это Shark.
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32331815
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Где-то я уже это читал - что Extent size должен быть кратным размеру strip - Точно! Ну как же - в рекомендации по использованию RAID в документации IBM DB2!
Гмм, я немного не про то спрашивал - не про зависимость Extent size от характеристик устройства хранения, а прор зависимость от храняхихся данных - ну там от длинны строки в таблице - неужели нет таких зависимостей?
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32331824
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Хотя длина строки здесь не при чём. Extent size это ведь кол-во страниц база пишет в контейнер прежде чем переключиться на другой контейнер.
Так вот именно если без RAID - зависит ли от чего этот параметр?
Как он влияет на I/O - вот что бы почитать. Или ни от чего не зависит и ставить по умолчанию?
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32331917
IBMer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Если у тебя нет RAID но есть 2 диска на которых лежит ТБСП
...
Рейтинг: 0 / 0
Разбивка таблицы на разделы.
    #32331938
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Извините, мне показалась Ваша мысль не закончена?
...
Рейтинг: 0 / 0
25 сообщений из 36, страница 1 из 2
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Разбивка таблицы на разделы.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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