Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
andrey_anonymous
Боюсь, тут все не так просто.
- конкурирующие сессии (многопользовательское окружение) создадут те же самые проблемы для TeraData.


Несомненно, многопользовательское окружение создаёт неудобства любой СУБД. Однако, в случае разделяемых ресурсов, конкуренция за них сильнее. По-моему, это достаточно очевидно.
Тут вопрос сравнения архитектур заключается в том, насколько накладные на постоянное перемещение данных по интерконнекту отличаются от накладных по борьбе за разделяемый ресурс.

andrey_anonymous
- на shared disk можно при желании собрать систему, распределяющую и обрабатывающую данные похожим на shared-nothing способом


А это как же? Вижу противоречие. Вроде бы разные принципы - в одном случае интерконнект нужен, в другом - общие диски.


andrey_anonymous
а вот обратное неверно, следовательно, shared nothing by design решает более узкий класс задач.


Прямо в точку. Терадата не позиционировалась никогда как OLTP, она изначально позиционировалась как СУБД для хранилищ данных, в то время как Оракл - наоборот изначально дизайнился как OLTP. Только потом начали вводить разные фичи для поддержки хранилищ данных, но это с недавнего времени по сравнению с временем жизни Терадаты.

kmike
В общем, хотелось бы услышать суть-чем "закрытое" решение от Терадаты лучше, чем та же DB2 DPF на commodity компонентах - каких-нибудь Оптеронах, что ли, с Infiniband


Не поянл термина "закрытое" решение. Вроде бы открытость определяется тем, как это решение может взаимодействовать с другими системами. Здесь полный спектр отурытости - самый ансишный SQL (в отличие от всяких там диалектов), полный набор connectivity (CLI, ODBC, JDBC, OLE DB и иже с ними).

С точки хрения commodity компонент - узлы Терадата - это двухпроцессорные SMP серверы на проwессорах Intel. А что касается интерконнекта - так это, на мой взгляд не совсем commodity.

Сравнивать Терадату с DB2 здесь достаточно сложно - я в деталях не знаком с реализацией массивно-параллельной архитектуры DB2. Есть определённые вещи типа меньшее количество хэш-партиций, чем в Терадате (потенциально более сильный перекос в данных), использование хэш только для распределения данных, но не для доступа, как в Терадате (то есть нужны лишние индексы), необходимость в узле-координаторе (узкое место), тогда, как в Терадате он не нужен. Поправьте, если я что-то не то назвал.

kmike
Пропускная способность Bynet как-то тоже не впечатляет на фоне Infiniband, которых, к тому же, в каждый узел можно натыкать много :)


Ещё раз хочу подчеркнуть, можно было бы и больше, но зачем, если это - не узкое место. Можно, конечно, потратиться, и забить все слоты этим infinibandom, но диски отэтого быстрее крутиться не станут.

kmike
В общем, вопрос о преимуществах Teradata открыт :)

Что делает даннцю дискуссию очень интересной, не так ли? :)

kmike
Ну если запросу понадобятся данные, находящиеся на недоступном узле-то оппа.
Для этого и существует например HACMP, чтобы запустить упавшую партицию на другом узле.


В Терадате такая хрень называется клика - объединение нескольких узлов, имеющих доступ к дискам соседних узлов для того, чтобы иметь возможность перезапустить умершие на одном узле процессы.
Помимо того есть фича, которой в других СУБД я не наблюдал. Называется fallback - это дублирование таблицы на разных узлах. Спасает от выхода из строя целой клики (как правило, в клике 8 узлов).



С уважением,
Константин Лисянский
http://lissianski.narod.ru
24 окт 06, 23:57    [3305221]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Андрей Прохоров
Member

Откуда:
Сообщений: 146
andrey_anonymous
В таких условиях и oracle справится с 1млрд не дороже терадаты - берем 10 10-процессорных SMP машин, 400 дисков, соответствующим образом проектируем базу...
И ведь тоже, зараза, распараллелит :)

Если почитать документацию по 10g, то не все выглядит так радужно. Для паралельного выполнения запросов нужно использовать partitioning. Чтобы обеспечить равномерную загрузку узлов, надо равномерно распределить данные между партициями, т.е. придется использовать hash partitioning (прощаемся с partitioning elimination), причем число партиций должно быть кратно степени 2 и количеству узлов. А теперь расскажите, как вы обеспечите равномерную загрузку 10 узлов, если 10 не является степенью 2?
Ну допустим подобрали partitioning с равномерным распредлением данных под конкретный join, а потом нужно сделать join по другой колонке, не по той, для которой partitioning планировали, что делать?
24 окт 06, 23:59    [3305226]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
andrey_anonymous
В таких условиях и oracle справится с 1млрд не дороже терадаты - берем 10 10-процессорных SMP машин, 400 дисков, соответствующим образом проектируем базу...
И ведь тоже, зараза, распараллелит :)


Ага. На каждую таблицу пишем вот такой create (по материалам любимого теста TPC-H):

drop table lineitem;
create table lineitem(
l_shipdate date,
l_orderkey number NOT NULL,
l_discount number NOT NULL,
l_extendedprice number NOT NULL,
l_suppkey number NOT NULL,
l_quantity number NOT NULL,
l_returnflag char(1),
l_partkey number NOT NULL,
l_linestatus char(1),
l_tax number NOT NULL,
l_commitdate date,
l_receiptdate date,
l_shipmode char(10),
l_linenumber number NOT NULL,
l_shipinstruct char(25),
l_comment varchar(44)
)
pctfree 1
pctused 99
initrans 10
storage (initial 1m next 16m pctincrease 0 freelist groups 8 freelists 99)
compress
parallel 256
nologging
partition by range (l_shipdate)
subpartition by hash(l_partkey)
subpartitions 256
(
partition item1 values less than (to_date('1992-01-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item2 values less than (to_date('1992-02-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item3 values less than (to_date('1992-03-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item4 values less than (to_date('1992-04-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item5 values less than (to_date('1992-05-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item6 values less than (to_date('1992-06-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item7 values less than (to_date('1992-07-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item8 values less than (to_date('1992-08-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item9 values less than (to_date('1992-09-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item10 values less than (to_date('1992-10-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item11 values less than (to_date('1992-11-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item12 values less than (to_date('1992-12-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item13 values less than (to_date('1993-01-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item14 values less than (to_date('1993-02-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item15 values less than (to_date('1993-03-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
HP BladeSystem 64P - TPC Benchmark H FDR.doc
© 2006 Hewlett Packard Company. All rights reserved 43
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item16 values less than (to_date('1993-04-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item17 values less than (to_date('1993-05-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item18 values less than (to_date('1993-06-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item19 values less than (to_date('1993-07-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item20 values less than (to_date('1993-08-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item21 values less than (to_date('1993-09-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item22 values less than (to_date('1993-10-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item23 values less than (to_date('1993-11-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item24 values less than (to_date('1993-12-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item25 values less than (to_date('1994-01-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item26 values less than (to_date('1994-02-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item27 values less than (to_date('1994-03-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item28 values less than (to_date('1994-04-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item29 values less than (to_date('1994-05-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item30 values less than (to_date('1994-06-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item31 values less than (to_date('1994-07-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item32 values less than (to_date('1994-08-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item33 values less than (to_date('1994-09-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item34 values less than (to_date('1994-10-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item35 values less than (to_date('1994-11-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item36 values less than (to_date('1994-12-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item37 values less than (to_date('1995-01-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item38 values less than (to_date('1995-02-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item39 values less than (to_date('1995-03-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item40 values less than (to_date('1995-04-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item41 values less than (to_date('1995-05-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item42 values less than (to_date('1995-06-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item43 values less than (to_date('1995-07-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item44 values less than (to_date('1995-08-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item45 values less than (to_date('1995-09-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item46 values less than (to_date('1995-10-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item47 values less than (to_date('1995-11-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item48 values less than (to_date('1995-12-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item49 values less than (to_date('1996-01-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item50 values less than (to_date('1996-02-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item51 values less than (to_date('1996-03-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item52 values less than (to_date('1996-04-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item53 values less than (to_date('1996-05-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item54 values less than (to_date('1996-06-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item55 values less than (to_date('1996-07-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item56 values less than (to_date('1996-08-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item57 values less than (to_date('1996-09-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item58 values less than (to_date('1996-10-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item59 values less than (to_date('1996-11-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item60 values less than (to_date('1996-12-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item61 values less than (to_date('1997-01-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item62 values less than (to_date('1997-02-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item63 values less than (to_date('1997-03-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item64 values less than (to_date('1997-04-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item65 values less than (to_date('1997-05-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item66 values less than (to_date('1997-06-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item67 values less than (to_date('1997-07-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item68 values less than (to_date('1997-08-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
HP BladeSystem 64P - TPC Benchmark H FDR.doc
© 2006 Hewlett Packard Company. All rights reserved 47
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item69 values less than (to_date('1997-09-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item70 values less than (to_date('1997-10-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item71 values less than (to_date('1997-11-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item72 values less than (to_date('1997-12-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item73 values less than (to_date('1998-01-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item74 values less than (to_date('1998-02-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item75 values less than (to_date('1998-03-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item76 values less than (to_date('1998-04-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item77 values less than (to_date('1998-05-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item78 values less than (to_date('1998-06-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item79 values less than (to_date('1998-07-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item80 values less than (to_date('1998-08-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item81 values less than (to_date('1998-09-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item82 values less than (to_date('1998-10-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item83 values less than (to_date('1998-11-01','YYYY-MM-DD'))
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128),
partition item84 values less than (MAXVALUE)
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128)
);


А когда конфигурацию нужно расширить до 20 машин, что делаем?
Выгружаем нафиг все данные, пишем create в два раза длиннее приведённого выше и загружаем всё заново?
Нанимаем дюжину админов, которые за этим всем будут присматривать и платим им безумные деньги - они же квалифицированные администраторы Оракл :)



К слову в Терадате вышеприведённый create будет выглядеть примерно так:

create table lineitem(
l_shipdate date,
l_orderkey number NOT NULL,
l_discount number NOT NULL,
l_extendedprice number NOT NULL,
l_suppkey number NOT NULL,
l_quantity number NOT NULL,
l_returnflag char(1),
l_partkey number NOT NULL,
l_linestatus char(1),
l_tax number NOT NULL,
l_commitdate date,
l_receiptdate date,
l_shipmode char(10),
l_linenumber number NOT NULL,
l_shipinstruct char(25),
l_comment varchar(44)
)
PRIMARY INDEX (l_partkey)
PARTITION BY RANGE_N(
l_shipdate BETWEEN DATE '1992-01-01' AND DATE '1998-12-31'
EACH INTERVAL '1' DAY, NO RANGE, UNKNOWN);

Терадата сама всё размажет и создаст нужные партиции. Ручками ничего создавать не надо. Удобно, правда?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
25 окт 06, 00:49    [3305283]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Андрей Прохоров
andrey_anonymous
В таких условиях и oracle справится с 1млрд не дороже терадаты - берем 10 10-процессорных SMP машин, 400 дисков, соответствующим образом проектируем базу...
И ведь тоже, зараза, распараллелит :)

Если почитать документацию по 10g, то не все выглядит так радужно. Для паралельного выполнения запросов нужно использовать partitioning.

1) Для parallel DML. Для select - совершенно необязательно.
2) Ну и чем это будет отличаться от терадаты?
Андрей Прохоров
Чтобы обеспечить равномерную загрузку узлов, надо равномерно распределить данные между партициями, т.е. придется использовать hash partitioning (прощаемся с partitioning elimination)
Мне казалось, что все сравнение крутится вокруг "быстро сделать full scan таблицы на миллиард записей". Какой тут partition pruning, Вы о чем?
Андрей Прохоров
, причем число партиций должно быть кратно степени 2 и количеству узлов.
А это уже полная ересь.
Андрей Прохоров
А теперь расскажите, как вы обеспечите равномерную загрузку 10 узлов, если 10 не является степенью 2?
Сами ерунду выдумали, сами и выкручивайтесь
Андрей Прохоров
Ну допустим подобрали partitioning с равномерным распредлением данных под конкретный join, а потом нужно сделать join по другой колонке, не по той, для которой partitioning планировали, что делать?

См. выше по дискуссии, вопрос обсуждался. Существенной разницы относительно TeraData не обнаружено.
25 окт 06, 03:57    [3305369]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Константин Лисянский
На каждую таблицу пишем вот такой create (по материалам любимого теста TPC-H):

Константин, я уверен, что в полном синтаксисе да еще с изрядной долей экстремизма в TeraData create можно написать ничуть не менее страшный
Вот только для решения задачи так много писать не надо.
Теперь про добавление узлов.
Тут, простите, Вы сами напросились - я специально не поднимал вопрос.
В TeraData придется физически переразмещать данные между узлами - значит, исходя из миллиарда записей, проканителимся недельку-другую :)
В oracle ничего никуда выгружать не надо.
Просто добавим узлы.
Если есть желание добавить разделов, то говорим alter table add/split partition.
Процессы не связанные сами по себе, кроме того, операции с разделами не требуют ограничения доступа пользователей ко всей таблице :Р
25 окт 06, 04:04    [3305371]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
kmike
Member

Откуда:
Сообщений: 286
Константин Лисянский
kmike
А что мешает Оракл, или, скажем, DB2 сконфигурировать с 400 дисками?


Ну, DB2 - это отдельный разговор. У них та же архитектура shared nothing, и, к слову сказать, они и являются основным конкурентом Терадаты в области хранилищ данных.

Ну дык чем оно тогда радикально отличается от Терадаты? Вот в чём вопрос-то...

Константин Лисянский

Но, Вы правы - и то и другое можно сконфигурировать с болшим количеством дисков.
Вопрос дальше - как размазывать таблицы по всему этому хозяйству, и в какой мере это помогает параллелизму в Оракл.

Дык в предельно упрощённом случае - SAME (stripe and mirror everything). Если уж совсем не заморачиваться. Вот только что проверил-0.58ГБ/c при сканировании таблицы, на довольно стареньком уже железе.

Константин Лисянский

Это, конечно, здорово, но к параллелизму не вижу как относится. Где параллельная сортировка и параллельные джойны?

Параллельная сортировка в Оракле точно есть.

Константин Лисянский

Оптимизатор Терадата учитывает физические параметры системы, на которой она работает, то есть частоту процессоров, скорость вращения жёстких дисков, пропускную способность bynet. К примеру, один и тот же запрос на системе одного размера при прочих равных может быть выполнен по-разному (например, будут выбраны разные алгоритмы джойнов). Вряд ли Оракл так умеет.

А нафига ему знать скорость вращения дисков? В DB2 для табличных пространств задаются 2 параметра, участвующих в расчёте стоимости: OVERHEAD и TRANSFERRATE, скорость процессора и пропускную способность сети оно тоже знает.

Константин Лисянский

Не совсем в железках - это всё вместе, и железки и софт. Аппаратно-программный комплекс.

Сейчас набегут борцы за снижение TCO и начнут кричать "single vendor lock-in!" и будут в чём-то правы :)
Опять тот же вопрос-какие преимущества даёт этот комплекс? Могу ли я для увеличения пропускной способности воткнуть Infiniband карточки в узлы? А по 7 штук в узел для обеспечения связи каждого узла с каждым в конфигурации из 8 узлов? Или проапгрейдить сеть на ещё более быструю?
25 окт 06, 06:24    [3305415]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
kmike
Member

Откуда:
Сообщений: 286
Константин Лисянский

Оракл - наоборот изначально дизайнился как OLTP.

Странно, а я тут давеча читал научно-фантастическую книжку "Everyone else must fail" про Эллисона, дык там пишут, что Оракл стали затачивать под OLTP только после того, как их нагнул Sybase, и была это примерно версия 7...

Константин Лисянский

Не поянл термина "закрытое" решение.
..
С точки хрения commodity компонент - узлы Терадата - это двухпроцессорные SMP серверы на проwессорах Intel. А что касается интерконнекта - так это, на мой взгляд не совсем commodity.

Ну я имел в виду то, что необязательно покупать всё решение у одного поставщика. И возможность перелезть на другое железо в случае чего. Пользователям каких-нибудь HP-PA это должно быть близкО :)
Ну и стандартный интерконнект тоже плюс - вдруг придётся расти. Или место в серверной кончится и придётся выносить новые узлы в другое здание (реальный случай). С GigE в этом случае, естессно, халява.
Кстати, какое ограничение на длину шнурка у bynet?

Константин Лисянский

Есть определённые вещи типа меньшее количество хэш-партиций, чем в Терадате (потенциально более сильный перекос в данных), использование хэш только для распределения данных, но не для доступа, как в Терадате (то есть нужны лишние индексы), необходимость в узле-координаторе (узкое место), тогда, как в Терадате он не нужен. Поправьте, если я что-то не то назвал.

А сколько хэш-партиций у Терадаты?
Насчёт индексов я не очень уверен, что это минус- насколько я понимаю, хэш отрабатывает только строгое равенство. Если использовать этот столбец только для джойнов-тогда да, хэш годится.
Про координатор я не совсем понял... А где у Терадаты происходит объединение результатов, полученных от нескольких узлов? Клиент же цепляется, допустим, по ODBC, только к какому-то одному узлу?

Константин Лисянский

Ещё раз хочу подчеркнуть, можно было бы и больше, но зачем, если это - не узкое место. Можно, конечно, потратиться, и забить все слоты этим infinibandom, но диски отэтого быстрее крутиться не станут.

Можно здесь подробнее? Допустим, есть таблицы T1 и T2 со столбцами A,B,C, и A используется для распределения по узлам. Как будет выполняться join T1 и T2 по условию T1.B=T2.B ?

Константин Лисянский

Помимо того есть фича, которой в других СУБД я не наблюдал. Называется fallback - это дублирование таблицы на разных узлах. Спасает от выхода из строя целой клики (как правило, в клике 8 узлов).

Ну вот это в принципе интересно. Но думаю, что реально только за счёт того, что Терадата заточена строго под DWH. Потому как по определению, это должен быть синхронный процесс, что при OLTP убьёт всю систему сразу. ИМХО.
25 окт 06, 06:51    [3305434]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Константин Лисянский
Ага. На каждую таблицу пишем вот такой create (по материалам любимого теста TPC-H):


Требую справедливости
drop table lineitem;
create table lineitem(
l_shipdate date,
l_orderkey number NOT NULL,
l_discount number NOT NULL,
l_extendedprice number NOT NULL,
l_suppkey number NOT NULL,
l_quantity number NOT NULL,
l_returnflag char(1),
l_partkey number NOT NULL,
l_linestatus char(1),
l_tax number NOT NULL,
l_commitdate date,
l_receiptdate date,
l_shipmode char(10),
l_linenumber number NOT NULL,
l_shipinstruct char(25),
l_comment varchar(44)
)
pctfree 1
pctused 99
initrans 10
storage (initial 1m next 16m pctincrease 0 freelist groups 8 freelists 99)
compress
parallel 256
nologging
partition by range (l_shipdate)
subpartition by hash(l_partkey)
subpartitions 256 
store in ( tsd1,tsd2,tsd3,tsd4,tsd5,tsd6,tsd7,tsd8,tsd9,tsd10,tsd11,
tsd12,tsd13,tsd14,tsd15,tsd16,tsd17,tsd18,tsd19,tsd20,tsd21,tsd22,
tsd23,tsd24,tsd25,tsd26,tsd27,tsd28,tsd29,tsd30,tsd31,tsd32,tsd33,
tsd34,tsd35,tsd36,tsd37,tsd38,tsd39,tsd40,tsd41,tsd42,tsd43,tsd44,
tsd45,tsd46,tsd47,tsd48,tsd49,tsd50,tsd51,tsd52,tsd53,tsd54,tsd55,
tsd56,tsd57,tsd58,tsd59,tsd60,tsd61,tsd62,tsd63,tsd64,tsd65,tsd66,
tsd67,tsd68,tsd69,tsd70,tsd71,tsd72,tsd73,tsd74,tsd75,tsd76,tsd77,
tsd78,tsd79,tsd80,tsd81,tsd82,tsd83,tsd84,tsd85,tsd86,tsd87,tsd88,
tsd89,tsd90,tsd91,tsd92,tsd93,tsd94,tsd95,tsd96,tsd97,tsd98,tsd99,
tsd100,tsd101,tsd102,tsd103,tsd104,tsd105,tsd106,tsd107,tsd108,
tsd109,tsd110,tsd111,tsd112,tsd113,tsd114,tsd115,tsd116,tsd117,
tsd118,tsd119,tsd120,tsd121,tsd122,tsd123,tsd124,tsd125,tsd126,
tsd127, tsd128)
(
partition item1 values less than (to_date('1992-01-01','YYYY-MM-DD')),
partition item2 values less than (to_date('1992-02-01','YYYY-MM-DD')),
partition item3 values less than (to_date('1992-03-01','YYYY-MM-DD')),
partition item4 values less than (to_date('1992-04-01','YYYY-MM-DD')),
partition item5 values less than (to_date('1992-05-01','YYYY-MM-DD')),
partition item6 values less than (to_date('1992-06-01','YYYY-MM-DD')),
partition item7 values less than (to_date('1992-07-01','YYYY-MM-DD')),
partition item8 values less than (to_date('1992-08-01','YYYY-MM-DD')),
partition item9 values less than (to_date('1992-09-01','YYYY-MM-DD')),
partition item10 values less than (to_date('1992-10-01','YYYY-MM-DD')),
partition item11 values less than (to_date('1992-11-01','YYYY-MM-DD')),
partition item12 values less than (to_date('1992-12-01','YYYY-MM-DD')),
partition item13 values less than (to_date('1993-01-01','YYYY-MM-DD')),
partition item14 values less than (to_date('1993-02-01','YYYY-MM-DD')),
partition item15 values less than (to_date('1993-03-01','YYYY-MM-DD')),
partition item16 values less than (to_date('1993-04-01','YYYY-MM-DD')),
partition item17 values less than (to_date('1993-05-01','YYYY-MM-DD')),
partition item18 values less than (to_date('1993-06-01','YYYY-MM-DD')),
partition item19 values less than (to_date('1993-07-01','YYYY-MM-DD')),
partition item20 values less than (to_date('1993-08-01','YYYY-MM-DD')),
partition item21 values less than (to_date('1993-09-01','YYYY-MM-DD')),
partition item22 values less than (to_date('1993-10-01','YYYY-MM-DD')),
partition item23 values less than (to_date('1993-11-01','YYYY-MM-DD')),
partition item24 values less than (to_date('1993-12-01','YYYY-MM-DD')),
partition item25 values less than (to_date('1994-01-01','YYYY-MM-DD')),
partition item26 values less than (to_date('1994-02-01','YYYY-MM-DD')),
partition item27 values less than (to_date('1994-03-01','YYYY-MM-DD')),
partition item28 values less than (to_date('1994-04-01','YYYY-MM-DD')),
partition item29 values less than (to_date('1994-05-01','YYYY-MM-DD')),
partition item30 values less than (to_date('1994-06-01','YYYY-MM-DD')),
partition item31 values less than (to_date('1994-07-01','YYYY-MM-DD')),
partition item32 values less than (to_date('1994-08-01','YYYY-MM-DD')),
partition item33 values less than (to_date('1994-09-01','YYYY-MM-DD')),
partition item34 values less than (to_date('1994-10-01','YYYY-MM-DD')),
partition item35 values less than (to_date('1994-11-01','YYYY-MM-DD')),
partition item36 values less than (to_date('1994-12-01','YYYY-MM-DD')),
partition item37 values less than (to_date('1995-01-01','YYYY-MM-DD')),
partition item38 values less than (to_date('1995-02-01','YYYY-MM-DD')),
partition item39 values less than (to_date('1995-03-01','YYYY-MM-DD')),
partition item40 values less than (to_date('1995-04-01','YYYY-MM-DD')),
partition item41 values less than (to_date('1995-05-01','YYYY-MM-DD')),
partition item42 values less than (to_date('1995-06-01','YYYY-MM-DD')),
partition item43 values less than (to_date('1995-07-01','YYYY-MM-DD')),
partition item44 values less than (to_date('1995-08-01','YYYY-MM-DD')),
partition item45 values less than (to_date('1995-09-01','YYYY-MM-DD')),
partition item46 values less than (to_date('1995-10-01','YYYY-MM-DD')),
partition item47 values less than (to_date('1995-11-01','YYYY-MM-DD')),
partition item48 values less than (to_date('1995-12-01','YYYY-MM-DD')),
partition item49 values less than (to_date('1996-01-01','YYYY-MM-DD')),
partition item50 values less than (to_date('1996-02-01','YYYY-MM-DD')),
partition item51 values less than (to_date('1996-03-01','YYYY-MM-DD')),
partition item52 values less than (to_date('1996-04-01','YYYY-MM-DD')),
partition item53 values less than (to_date('1996-05-01','YYYY-MM-DD')),
partition item54 values less than (to_date('1996-06-01','YYYY-MM-DD')),
partition item55 values less than (to_date('1996-07-01','YYYY-MM-DD')),
partition item56 values less than (to_date('1996-08-01','YYYY-MM-DD')),
partition item57 values less than (to_date('1996-09-01','YYYY-MM-DD')),
partition item58 values less than (to_date('1996-10-01','YYYY-MM-DD')),
partition item59 values less than (to_date('1996-11-01','YYYY-MM-DD')),
partition item60 values less than (to_date('1996-12-01','YYYY-MM-DD')),
partition item61 values less than (to_date('1997-01-01','YYYY-MM-DD')),
partition item62 values less than (to_date('1997-02-01','YYYY-MM-DD')),
partition item63 values less than (to_date('1997-03-01','YYYY-MM-DD')),
partition item64 values less than (to_date('1997-04-01','YYYY-MM-DD')),
partition item65 values less than (to_date('1997-05-01','YYYY-MM-DD')),
partition item66 values less than (to_date('1997-06-01','YYYY-MM-DD')),
partition item67 values less than (to_date('1997-07-01','YYYY-MM-DD')),
partition item68 values less than (to_date('1997-08-01','YYYY-MM-DD')),
partition item69 values less than (to_date('1997-09-01','YYYY-MM-DD')),
partition item70 values less than (to_date('1997-10-01','YYYY-MM-DD')),
partition item71 values less than (to_date('1997-11-01','YYYY-MM-DD')),
partition item72 values less than (to_date('1997-12-01','YYYY-MM-DD')),
partition item73 values less than (to_date('1998-01-01','YYYY-MM-DD')),
partition item74 values less than (to_date('1998-02-01','YYYY-MM-DD')),
partition item75 values less than (to_date('1998-03-01','YYYY-MM-DD')),
partition item76 values less than (to_date('1998-04-01','YYYY-MM-DD')),
partition item77 values less than (to_date('1998-05-01','YYYY-MM-DD')),
partition item78 values less than (to_date('1998-06-01','YYYY-MM-DD')),
partition item79 values less than (to_date('1998-07-01','YYYY-MM-DD')),
partition item80 values less than (to_date('1998-08-01','YYYY-MM-DD')),
partition item81 values less than (to_date('1998-09-01','YYYY-MM-DD')),
partition item82 values less than (to_date('1998-10-01','YYYY-MM-DD')),
partition item83 values less than (to_date('1998-11-01','YYYY-MM-DD')),
partition item84 values less than (MAXVALUE)
);
25 окт 06, 10:20    [3306113]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Константин Лисянский
Но, Вы правы - и то и другое можно сконфигурировать с болшим количеством дисков.
Вопрос дальше - как размазывать таблицы по всему этому хозяйству, и в какой мере это помогает параллелизму в Оракл.

Размазывать можно:
- Руками
- Автоматизированно посредством темплейтов для описания hash subpartitions
- Автоматически, положившись на ASM

Параллелизму способствует в достаточной степени.

Лирическое отступление
До сих пор обсуждение шло в достаточно конструктивном контексте - мы оба (надеюсь) узнавали что-то новое.
Но вчерашние Ваши посты неожиданно наполнились, простите, инсинуациями.
Я физически не смогу опровергнуть каждое ложное утверждение относительно oracle - мне просто не хватит на это ни времени, ни сил.
Поэтому для сохранения прежнего довольно комфортного духа дискуссии прошу все-таки избегать непонятно откуда взявшихся предположений, особенно высказанных в полуутвердительной форме.


Константин Лисянский
kmike
А что, на Терадате можно только по одному запросу за раз запускать? :)

Ага, вроде того :)

Надеюсь, это была шутка?
Константин Лисянский
andrey_anonymous
проще внести поправки относительно показателей, полученных на некоторой референсной методике, чем гадать как проявит себя "реальная" жизнь в конкретном окружении под конкроетной задачей.

Хромает методика референсная. Если взять, кпримеру, проблему соединения 10 таблиц, то там уже такая комбинаторика, что если оптимизатор не использует эвристические подходы для отбрасывания заведомо дорогих вариантов.

Это не самая большая проблема. По крайней мере для оракеля.
Комбинаторика комбинаторикой, но построение плана требуется только при первом выполнении запроса. При этом оптимизатор ограничен во времени и действительно может не рассмотреть часть вариантов, однако и на эту проблему оракл предлагает решение: есть режим работы оптимизатора, в котором он просто генерирует планы, не думая о временных рамках.
Планы можуг быть сохранены для последующего использования и даже экспортированы на другую БД :)
Эвристика тоже имеет место, но релиз за релизом ее роль падает - она скорее мешает в нетривиальных случаях (вроде того, на который я давал забракованную Вами ссылку).
Константин Лисянский
andrey_anonymous
Как хотите. На мой взгляд показателен именно в том смысле, что оптимизатор oracle воспринимает и обрабатывает разделы таблицы как независимые наборы данных и имеет механизмы для объединения результатов.
Это, конечно, здорово, но к параллелизму не вижу как относится. Где параллельная сортировка и параллельные джойны?

Константин, что за неуместные наезды?
Нате Вам параллельную сортировку:
SQL> create table ane_t_pj_1(k number primary key, v varchar2(128))
  2  partition by range (k)
  3  ( partition ane_t_pj_1_p1 values less than (100)
  4  , partition ane_t_pj_1_p2 values less than (200)
  5  , partition ane_t_pj_1_p3 values less than (300)
  6  ) parallel 2;

Table created

SQL> insert into ane_t_pj_1 select rownum, 'v='||rownum from dual connect by level < 300;

299 rows inserted

SQL> explain plan for select * from ane_t_pj_1 t order by v;

Explained

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2080730224
-----------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation               | Name       | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |            |   246 | 66666 |     3  (34)| 00:00:01 |       |       |        |      |            |
|   1 |  PX COORDINATOR         |            |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (ORDER)    | :TQ10001   |   246 | 66666 |     3  (34)| 00:00:01 |       |       |  Q1,01 | P->S | QC (ORDER) |
|   3 |    SORT ORDER BY        |            |   246 | 66666 |     3  (34)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   4 |     PX RECEIVE          |            |   246 | 66666 |     2   (0)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   5 |      PX SEND RANGE      | :TQ10000   |   246 | 66666 |     2   (0)| 00:00:01 |       |       |  Q1,00 | P->P | RANGE      |
|   6 |       PX BLOCK ITERATOR |            |   246 | 66666 |     2   (0)| 00:00:01 |     1 |     3 |  Q1,00 | PCWC |            |
|   7 |        TABLE ACCESS FULL| ANE_T_PJ_1 |   246 | 66666 |     2   (0)| 00:00:01 |     1 |     3 |  Q1,00 | PCWP |            |
-----------------------------------------------------------------------------------------------------------------------------------

14 rows selected

SQL> 

Константин Лисянский
andrey_anonymous
Оптимизатор у оракеля достаточно сложен.
Расчет ведется по LIO, но оценки стоимости зависят и от вероятности встретить нужные блоки индекса в буферном кэше, и от количества блоков, считываемых при FTS за одну операцию ввода-вывода, и от соотношения времени считывания такого "пакета" к физическому чтению одного блока (обычно блок индекса при кэш-промахе).
Оптимизатор Терадата учитывает физические параметры системы, на которой она работает, то есть частоту процессоров, скорость вращения жёстких дисков, пропускную способность bynet. К примеру, один и тот же запрос на системе одного размера при прочих равных может быть выполнен по-разному (например, будут выбраны разные алгоритмы джойнов). Вряд ли Оракл так умеет.

Ложное предположение. Умеет, причем весьма неплохо.
И производительность CPU учесть, и производительность IO, и планчик подобрать.
Константин Лисянский
Так как он весь из себя переносимый и должен работать на всём, включая утюги и электрочайники :),

Это никак не относится к алгоритмам оптимизатора.
Константин Лисянский
он и оперирует логическими показателями, что на мой взгляд есть недостаток.
Наоборот. Если терадата не умеет адекватно оценить стоимость индексного доступа в зависимости от степени его кэшированности - скорее всего легко строится тест-кейс, показывающий, что оптимизатор категорически неправ :)
Либо Вы чего-то не договариваете.
Константин Лисянский
Кстати, несмотря на то, что оптимизатор "достаточно сложен", я так понимаю, народ его зинтует безбожно.

Вы понимаете неверно.
Константин Лисянский
andrey_anonymous
В таких условиях и oracle справится с 1млрд не дороже терадаты - берем 10 10-процессорных SMP машин, 400 дисков, соответствующим образом проектируем базу...
И ведь тоже, зараза, распараллелит :)
Выходит, все преимущество TeraData - в железках?

Распараллелит, но как? Это к вопросу про показать план запроса.
Скажите какого - я покажу.
Мы мечемся в обсуждении с кейса на кейс без видимой системы и те механизмы, которые приводятся в заслугу терадате уже через два поста могут быть поставлены в укор оракелю ("а вот если мы его вот эдак - то оно работать будет плохо").
Поэтому и не привожу.
Константин Лисянский
Не совсем в железках - это всё вместе, и железки и софт. Аппаратно-программный комплекс.

Программно-аппаратным комплексом называется все что угодно.
Если возможно, выделите пожалуйста из этого словосочетания ключевые аспекты (например: "ByNet: железка, умеет SMJ и сегментирование сети, разгружает узел, к которому подключен клиент. Аналоги: нет. Альтернативы: кластерный интерконнект").
25 окт 06, 11:36    [3306809]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Константин Лисянский
andrey_anonymous
Боюсь, тут все не так просто.
- конкурирующие сессии (многопользовательское окружение) создадут те же самые проблемы для TeraData.
Несомненно, многопользовательское окружение создаёт неудобства любой СУБД. Однако, в случае разделяемых ресурсов, конкуренция за них сильнее. По-моему, это достаточно очевидно.
По-моему, недостаточно...
Покажите, если не сложно.
Константин Лисянский
Тут вопрос сравнения архитектур заключается в том, насколько накладные на постоянное перемещение данных по интерконнекту отличаются от накладных по борьбе за разделяемый ресурс.
Интерконнект дороже дисковых чтений, а затраты на конкуренцию ИМХО Вы несколько преувеличиваете.
Константин Лисянский
andrey_anonymous
- на shared disk можно при желании собрать систему, распределяющую и обрабатывающую данные похожим на shared-nothing способом
А это как же? Вижу противоречие. Вроде бы разные принципы - в одном случае интерконнект нужен, в другом - общие диски.
Оракель всеядный - у него есть и то, и другое ;)
Константин Лисянский
andrey_anonymous
а вот обратное неверно, следовательно, shared nothing by design решает более узкий класс задач.
но это с недавнего времени по сравнению с временем жизни Терадаты.
Как все, безусловно, понимают, абсолютное сравнение возраста решений мало что дает в плане оценки их современного состояния.
Давайте больше не будем к этому возвращаться, иначе нас всех победит какой-нибудь древний MUMPS
Константин Лисянский
kmike
Пропускная способность Bynet как-то тоже не впечатляет на фоне Infiniband, которых, к тому же, в каждый узел можно натыкать много :)

Ещё раз хочу подчеркнуть, можно было бы и больше, но зачем, если это - не узкое место.
Вот это и непонятно. Ввиду отсутствия общих дисков на некоторых запросах по байнету должен пролезть чуть ли не весь трафик. А байнет то "не заткнешь", то "не быстрый, но узким местом не является".
Какая-то мистика.
Константин Лисянский
Можно, конечно, потратиться, и забить все слоты этим infinibandom, но диски отэтого быстрее крутиться не станут.
Зато передачи с каждого на каждый узел (полагаю, Вы вполне способны представить соответствующий запрос к БД) будут не так сильно тормозить.
Константин Лисянский
kmike
В общем, вопрос о преимуществах Teradata открыт :)
Что делает даннцю дискуссию очень интересной, не так ли? :)
Безусловно.
Если бы Вы сумели показать преимущества, то дискуссия давно бы увяла - народ сказал бы "КУ" и выдохнул наконец.
Константин Лисянский
В Терадате такая хрень называется клика - объединение нескольких узлов, имеющих доступ к дискам соседних узлов для того, чтобы иметь возможность перезапустить умершие на одном узле процессы.
То есть все-таки shared disk есть?
И поясните плиз, каким образом доступ к дискам позволяет перезапустить узел? Это опечатка?
Константин Лисянский
Помимо того есть фича, которой в других СУБД я не наблюдал. Называется fallback - это дублирование таблицы на разных узлах. Спасает от выхода из строя целой клики (как правило, в клике 8 узлов).

Ну тут понятно - в shared disk оно просто без надобности :)
25 окт 06, 11:52    [3306988]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Андрей Прохоров
Member

Откуда:
Сообщений: 146
andrey_anonymous
Андрей Прохоров
, причем число партиций должно быть кратно степени 2 и количеству узлов.

А это уже полная ересь.

Oracle Database Data Warehousing Guide 10g Release 2
Oracle Database uses a linear hashing algorithm and to prevent data from clustering within specific partitions, you should define the number of partitions by a power of two (for example, 2, 4, 8).
andrey_anonymous
Андрей Прохоров
А теперь расскажите, как вы обеспечите равномерную загрузку 10 узлов, если 10 не является степенью 2?

Сами ерунду выдумали, сами и выкручивайтесь

Oracle Database Data Warehousing Guide 10g Release 2
The number of partitions used for partition-wise joins should, if possible, be a multiple of the number of query servers. ...
This is because, in the beginning of the execution, each parallel execution server works on a different partition pair. At the end of this first phase, only one pair is left. Thus, a single parallel execution server joins this remaining pair while all other parallel execution servers are idle.


Расскажите разработчикам Oracle, что они по Ваше мнению "ересь" и "ерунду" придумавают...
Или почитайте документацию перед тем как посты писать
25 окт 06, 22:44    [3311432]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
andrey_anonymous
Константин, я уверен, что в полном синтаксисе да еще с изрядной долей экстремизма в TeraData create можно написать ничуть не менее страшный


Может, конечно, быть и более сложный create, но указывать Терадате, куда девать данные не нужно - она всё сама делает автоматически.

andrey_anonymous
В TeraData придется физически переразмещать данные между узлами - значит, исходя из миллиарда записей, проканителимся недельку-другую :)


Миллиард - это небольшая таблица. Я же привёл пример того, что при 10 узлах на каждый узел придётся всего по 10 миллионов записей. Их и нужно будет перекидать при добалвении новых узлов.

andrey_anonymous
В oracle ничего никуда выгружать не надо.
Просто добавим узлы.


Полагаю, узлы для повышения производительности системы. В Терадате добавление новых узлов означает увеличение степени параллелизма путём увеличения количества процессов и уменьшения количества данных, которые один процесс должен обрабатывать.
В случае Оракл, насколько я понял из вышеприведённого create, количество партиций и их размещение задаётся во время этого самого криэйта. Соответственно, чтобы достичь аналогичного эффекта в Оракл, нужно тоже переразмазать данные, что означает, что нужно добавить партиций, разместить их на новых дисках и перекинуть часть данных из старых партиций в новые. Не так ли? Так вот, вопрос заключается в том, как это делается в Оракл автоматически для всех таблиц (не вручную же пераразмазывать сотни таблиц).




С уважением,
Константин Лисянский
http://lissianski.narod.ru
25 окт 06, 22:45    [3311437]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
andrey_anonymous
Если есть желание добавить разделов, то говорим alter table add/split partition.
Процессы не связанные сами по себе, кроме того, операции с разделами не требуют ограничения доступа пользователей ко всей таблице


Это, несомненно, здорово. В Терадате партиции нельзя сплитить. Только удалять и добавлять новые. Это относится именно к партишионингу, а не к хэш-распределению, на которое повлиять нельзя кроме как выбором первичного индекса и которое делается автоматически для каждой таблицы.

С уважением,
Константин Лисянский
http://lissianski.narod.ru
25 окт 06, 23:05    [3311475]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Андрей Прохоров
Расскажите разработчикам Oracle, что они по Ваше мнению "ересь" и "ерунду" придумавают...
Или почитайте документацию перед тем как посты писать

Тезка, а теперь перечитайте Вами же приведенные цитаты, только не пропукайте слова и вооружитесь не фантазией, а словарем, ок?
И еще поищите в warehousing guide слово "granularity", и тоже читайте со словарем во избежание недопонимания.
:/
25 окт 06, 23:26    [3311508]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Андрей Прохоров
andrey_anonymous
Андрей Прохоров
, причем число партиций должно быть кратно степени 2 и количеству узлов.

А это уже полная ересь.

Oracle Database Data Warehousing Guide 10g Release 2
Oracle Database uses a linear hashing algorithm and to prevent data from clustering within specific partitions, you should define the number of partitions by a power of two (for example, 2, 4, 8).

C английского should переводится как должно бы - то есть носит рекомендательный характер. В данном случае Оракл рекомендует этот метод расчета кол-ва хэш партиций для улучшения равномерности распределения строк по партициям. Безо всяких проблем можно создать, скажем, 5 или 10 партиций - это разрешено. При добавлении/убивании хэш партиции Оракл сам перераспределит строки. Насколько я помню, это online операция (сохраняется доступность для пользователей).
Далее я заметил начавшуюся путаницу по поводу партиций - их у Оракла несколько типов (hash, range, list плюс несколько комбинированных). Те, что не хэш, по определению требует ручной работы (как то добавить партицию для нового диапазона дат). К слову, сплит хэш партиции - нонсенс по определению. И в Оракле их можно только добавлять или удалять.

Из других полезных фич Оракла - subpartitions and local indexes.
25 окт 06, 23:35    [3311530]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Константин Лисянский
Может, конечно, быть и более сложный create, но указывать Терадате, куда девать данные не нужно - она всё сама делает автоматически.
Ну оно и логично - вариантов-то небогато, один узел=1 хеш-раздел.
В оракеле такой жесткой связи нет, поэтому и синтакис побогаче. Но далеко не все конструкции являются обязательными - те же hash subpartitions начиная, АФАИР, с 9i, генерятся по шаблону при нарезке нового раздела. В восьмерке упрек в избыточной сложности был более справедлив.
Константин Лисянский
andrey_anonymous
В TeraData придется физически переразмещать данные между узлами - значит, исходя из миллиарда записей, проканителимся недельку-другую :)

Миллиард - это небольшая таблица. Я же привёл пример того, что при 10 узлах на каждый узел придётся всего по 10 миллионов записей. Их и нужно будет перекидать при добалвении новых узлов.
если мы к 10 имеющимся добавили 6 узлов - как будут перераспределяться данные? Если я правильно понимаю, переместить придется примерно 3/8 всех строк, а перед этим прочитать (пусть и параллельно) весь миллиард и перерасчитать хеши.
Кстати вопрос - узлы добавляются кучкой или по одному? (т.е. сколько раз будут физически перераспределяться данные?)
Еще один вопрос. В оракеле я могу "старые" разделы перевести в readonly, причем это не помешает при необходимости (например, при увеличении скорости поступления данных) изменить количество хеш-subpartitions в активных разделах.
Как с этим обстоят дела в терадате?
Как влияет перераспределение данных на журналы повторного выполнения и не является ли это ограничивающим фактором?
Константин Лисянский
andrey_anonymous
В oracle ничего никуда выгружать не надо. Просто добавим узлы.
Полагаю, узлы для повышения производительности системы. В Терадате добавление новых узлов означает увеличение степени параллелизма путём увеличения количества процессов и уменьшения количества данных, которые один процесс должен обрабатывать.
В случае Оракл, насколько я понял из вышеприведённого create, количество партиций и их размещение задаётся во время этого самого криэйта.
Или альтера. Да.
Константин Лисянский
Соответственно, чтобы достичь аналогичного эффекта в Оракл, нужно тоже переразмазать данные, что означает, что нужно добавить партиций, разместить их на новых дисках и перекинуть часть данных из старых партиций в новые. Не так ли?
Если цель - parallel DML, то, скорее всего (не во всех случаях), да.
Если выборки - то правило не такое жесткое.
Константин Лисянский
Так вот, вопрос заключается в том, как это делается в Оракл автоматически для всех таблиц (не вручную же пераразмазывать сотни таблиц).
Если работаем в схеме "rolling window", то просто добавляем новый раздел и переписываем шаблон размещения подразделов. Всю таблиц переразмещать при этом нет необходимости - по мере устаревания "неоптимальные" разделы сами уйдут в историю. Но можно, конечно, и ручками или инструментами.
25 окт 06, 23:43    [3311548]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Андрей Прохоров
Member

Откуда:
Сообщений: 146
andrey_anonymous
Тезка, а теперь перечитайте Вами же приведенные цитаты, только не пропукайте слова и вооружитесь не фантазией, а словарем, ок?
И еще поищите в warehousing guide слово "granularity", и тоже читайте со словарем во избежание недопонимания.

Похоже, что Вы документацию совсем читать не хотите. Для Вас цитирую в послений раз.
"The number of partitions determines the maximum degree of parallelism, because the partition is the smallest granule of parallelism for partial
partition-wise join operations."
"The maximum allowable DOP is the number of partitions. This might limit the utilization of the system and the load balancing across parallel execution
servers." и т.д.
Учите матчасть, прежде чем грубить на форуме.

Anton Demidov
Безо всяких проблем можно создать, скажем, 5 или 10 партиций - это разрешено. При добавлении/убивании хэш партиции Оракл сам перераспределит строки. Насколько я помню, это online операция (сохраняется доступность для пользователей). ...
К слову, сплит хэш партиции - нонсенс по определению. И в Оракле их можно только добавлять или удалять.

"Although the hash function's use of "add partition" logic dramatically improves the
manageability of hash partitioned tables, it means that the hash function can cause a skew if the number of partitions of a hash partitioned table, or the number of subpartitions in each partition of a composite table, is not a power of two. In the worst case, the largest partition can be twice the size of the smallest. So for optimal performance, create a number of partitions and subpartitions for each partition that is a power of two. For example, 2, 4, 8, 16, 32, 64, 128, and so on."

Да, похоже здесь стало совсем дурным тоном документацию читать.
Остается только ликбезом по Oracle заниматься
26 окт 06, 00:00    [3311590]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Андрей Прохоров
Anton Demidov
Безо всяких проблем можно создать, скажем, 5 или 10 партиций - это разрешено. При добавлении/убивании хэш партиции Оракл сам перераспределит строки. Насколько я помню, это online операция (сохраняется доступность для пользователей). ...
К слову, сплит хэш партиции - нонсенс по определению. И в Оракле их можно только добавлять или удалять.

"Although the hash function's use of "add partition" logic dramatically improves the
manageability of hash partitioned tables, it means that the hash function can cause a skew if the number of partitions of a hash partitioned table, or the number of subpartitions in each partition of a composite table, is not a power of two. In the worst case, the largest partition can be twice the size of the smallest. So for optimal performance, create a number of partitions and subpartitions for each partition that is a power of two. For example, 2, 4, 8, 16, 32, 64, 128, and so on."

Да, похоже здесь стало совсем дурным тоном документацию читать.
Остается только ликбезом по Oracle заниматься
Её не только читать надо уметь, но и понимать. У вас возник вопрос? Нашли где-то "нестыковочку"? Пишите об этом конкретно, выделите это жирным шрифтом, что бы сразу было понятно.
26 окт 06, 00:54    [3311669]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Павел Новокшонов
Member

Откуда: Moscow -> Atlanta, GA
Сообщений: 90
Немного о практической стороне дела. У моего настоящего клиента в системе ~2500 пользователей и ~5000 таблиц в хранилище. Крутится все на Teradata 86 узлов, диска 118TB, данных 35 TB. Пользователи в основном пишут ручками SQL, очень часто разный и навороченный, при этом частенько создают свои постоянные и временные таблицы. Все что мне нужно вбить им в головы – это то, что при создании таблицы есть колонка называемая Primary Index и она в идеале должна быть уникальна. Это все. Дальше Teradata сама равномерно размажет данные по AMP’ам и сбалансрует загрузку. Синтаксис большинства таблиц выглядит следующим образом:

Create table A (c1 int, ….) primary index c1

Partitioning в Oracle наверное действительно нужен для настройки OLTP систем. Точно также как в OLTP актуален вопрос использования кэша. Вопрос в другом – хранилище данных в маштабе компании Fortune 500 - это зачастую не статическая система - и сколько нужно возится с поддержкой table space’ов, dbspace’ов, перестраивать индексы (так было раньше по крайней мере) да еще платить кучу бабла армии DBA’ов. В Teradate’e всего этого нет, кроме последнего :-), но скорее для 1-2 DBA’ов. Из моего опыта с Informix, DB2 и Teradata - последняя гораздо эффективнее и легче в сопровождении чем все остальные основные СУБД. Система поставляется из n-го кол-ва узлов, c n-ми терабайтами доступного дискового пространства. Весь partitioning остается за кадром, все что остается сделать – это спроектировать структуру БД, выбрать primary index’ы и залить данные.

Появились новые данные – не проблема выбери правильно primary index’ы и залей новые таблицы. Много данных стало, система торомозит – не проблема купи у NCR узлов со стораджом и увеличь свой кластер. Терадата все сделает сама – легко и просто. Американцы это любят. Не надо заморачиваться и долго ломать голову.
26 окт 06, 06:18    [3311837]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Павел Новокшонов
Member

Откуда: Moscow -> Atlanta, GA
Сообщений: 90
andrey_anonymous
если мы к 10 имеющимся добавили 6 узлов - как будут перераспределяться данные? Если я правильно понимаю, переместить придется примерно 3/8 всех строк, а перед этим прочитать (пусть и параллельно) весь миллиард и перерасчитать хеши.
Кстати вопрос - узлы добавляются кучкой или по одному? (т.е. сколько раз будут физически перераспределяться данные?)
Еще один вопрос. В оракеле я могу "старые" разделы перевести в readonly, причем это не помешает при необходимости (например, при увеличении скорости поступления данных) изменить количество хеш-subpartitions в активных разделах.
Как с этим обстоят дела в терадате?
Как влияет перераспределение данных на журналы повторного выполнения и не является ли это ограничивающим фактором?


Данные будут размазаны равномерно между 16 узлами. В этом ключевой вопрос оптимальной сбалансированности системы. Хэши придется перерасчитать. Узлы добавляются кучей. Журналов транзакций в ХД как правило нет. Т.е. в Teradata есть механизм журналирования как в любой СУБД, но на практике его редко используют. Это не OLTP.
26 окт 06, 06:46    [3311853]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Павел Новокшонов
Из моего опыта с Informix, DB2 и Teradata - последняя гораздо эффективнее и легче в сопровождении чем все остальные основные СУБД.

Ок, спасибо - первое названное реальное преимущество терадата перед системами общего назначения для DWH.
Еще что-то сможете вспомнить?
Павел Новокшонов
Данные будут размазаны равномерно между 16 узлами. В этом ключевой вопрос оптимальной сбалансированности системы. Хэши придется перерасчитать. Узлы добавляются кучей.

Павел, Константин - моя оценка времени "неделька-другая" на удвоение количества узлов от реальности, скорее всего, далека, не могли бы Вы все-таки привести Вашу оценку?
Второй вопрос - будет ли база доступна пользователям в процессе?
Павел Новокшонов
Журналов транзакций в ХД как правило нет. Т.е. в Teradata есть механизм журналирования как в любой СУБД, но на практике его редко используют. Это не OLTP.

Вообще журнал применяется при восстановлении из hot backup.
Альтернатива - хранение всей первичной информации, загруженной в хранилище после создания последней резервной копии (этакий "ручной" журнал).
Сколько времени занимает backup в отсутствие журнала, требуется ли ограничивать доступ пользователей?
Задавая эти вопросы, я хочу попробовать составить впечатление о типовом коэффициенете готовности систем на базе TeraData.

Исходя из материалов топика я пришел к выводу, что TeraData вроде как непригодна для смешанных DWH+OLTP (BSS/OSS) систем - не ошибаюсь ли я?
26 окт 06, 10:38    [3312600]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Андрей Прохоров
andrey_anonymous
Тезка, а теперь перечитайте Вами же приведенные цитаты, только не пропускайте слова и вооружитесь не фантазией, а словарем, ок?
Похоже, что Вы докуметацию совсем читать не хотите. Для Вас цитирую в послений раз.

Цитатки неаккуратно из контекста вырезаете.
В первой, к примеру, обсуждается исключительно PARTITION-WISE JOIN.
И ничего более. Вы же цитируете, словно это общее правило и системное ограничение. Вторая тоже без контекста ни о чем не говорит.
И ни одна из них не подтверждает Ваши инсинуации:
1) "Для паралельного выполнения запросов нужно использовать partitioning"
Утверждение ложно, поскольку данное ограничение действует не на любые запросы.
Если бы Вы удосужились правильно описать классы запросов, для которых ограничение актуально - проблем бы не было.
2) "Чтобы обеспечить равномерную загрузку узлов .... придется использовать hash partitioning"
Утверждение ложно. С учетом конкретного содержимого равномерное распределение данных может быть достигнуто и на range, и на list.
3) "как вы обеспечите равномерную загрузку 10 узлов, если 10 не является степенью 2"
Для начала сумейте показать, что имеющаяся неравномерность (напомню приведенную Вами цитату, в худшем случае самый большой раздел может оказаться в два раза больше самого маленького) заметно повлияет на время исполнения запроса, если разделов более двух.
Если же немножко отвлечься от стиля документалистов oracle и вспомнить, что речь таки идет о хеш-функции, то можно достаточно легко предложить пример исходных данных, которые улягутся, к примеру, всей толпой в один и тот же раздел. Актуально и для TeraData, и для Oracle, и вообще для любой системы, разделяющей данные по хеш.

Что до "хамства в форуме" - приношу свои извинения если обидел.
Однако не снимаю упрека в некорректном цитировании и неверном толковании документации.
26 окт 06, 11:27    [3313085]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
andrey_anonymous
Ну оно и логично - вариантов-то небогато, один узел=1 хеш-раздел.


Это довольноо далеко от истины. 1 узел = (65535 / количество узлов в системе) разделов (в терминах Терадаты hash bucket).
То есть в любой системе Терадата 65535 хэш-бакетов, которые равномерно распределяются между AMPами (не узлами, поскольку AMPы могут мигрировать на другие узлы, в случае падения из "родных" узлов).
Механихм распределения довольно прост - хэш-карта, хранящая соответствие между номером AMP и номером хэш-бакета.
Наличие такого большого количества хэш-бакетов обеспечивает равномерное распределение данных даже на очень больших таблицах, что повышает степень параллелизма сканирования таблицы.


andrey_anonymous
Если цель - parallel DML, то, скорее всего (не во всех случаях), да.
Если выборки - то правило не такое жесткое.


А не могли бы Вы пояснить какая между ними разница? Разве выборка - это не DML?
Мне сложно понять, просто в Терадате параллелится всё без исключения.

Кстати, тут по ходу возникли вопросы по поводу параллелизма триггеров, UDF и хранимых процедур. Как с этим в Оракл?

andrey_anonymous
Павел, Константин - моя оценка времени "неделька-другая" на удвоение количества узлов от реальности, скорее всего, далека, не могли бы Вы все-таки привести Вашу оценку?
Второй вопрос - будет ли база доступна пользователям в процессе?


Думаю, у Павла лучше получится сделать оценку - у него система помассивнее будет.
На вопрос о сканировании миллиардной таблицы - у нашего клиента сейчас 4 узла. Таблица в 3 миллиарда записей сканируется где-то минут 5-6. Правда, это довольно узкая таблица.

В процессе апгрейда база на некоторое время недоступна для пользователей (поскольку данные в это время перехешируются).


Кстати ещё про одно преимущество (оно косвенно объясняет и лучшее сопровождение) - в Терадате нужно гораздо меньше индексов и агрегатов. Таким образом, оверхед по дискам меньше (ну, или, если перефразировать - при том же объёме сырых дисков у Терадаты больше полежного пространства).
Терадата, ещё например умеет динамически распределять ресурсы системы в зависимости от приоритетов пользователей (приложений) на основе весов их "групп". Есть механизм типа гейткипера, который может отстреливать всяческие декартовы произведения и иже с ними, а есть тот, который на ходу выделят ресурсы каждой сессии в зависимсоти от того, кто есть по соседству. Есть замечательные механизмы анализа workload и выдачи рекомендаций о его оптимизации (типа построения индексов, сбора статистики и т.д).
Именно благодаря этим механизмам Терадата может отлично сочетать в себе запросы типа сложного DSS с кучей джойнов и т.д. и коротких запросов типа запроса агента колл-центра типа "выдать мне информацию по этому клиенту" с гарантированным SLA.

andrey_anonymous
Вообще журнал применяется при восстановлении из hot backup.
Альтернатива - хранение всей первичной информации, загруженной в хранилище после создания последней резервной копии (этакий "ручной" журнал).
Сколько времени занимает backup в отсутствие журнала, требуется ли ограничивать доступ пользователей?
Задавая эти вопросы, я хочу попробовать составить впечатление о типовом коэффициенете готовности систем на базе TeraData.

Исходя из материалов топика я пришел к выводу, что TeraData вроде как непригодна для смешанных DWH+OLTP (BSS/OSS) систем - не ошибаюсь ли я?


В Терадате существует понятие транзакционного журнала (transient journal - на одну транзакцию) и постоянного журнала (permanent journal). В этом плане, думаю, она не отличается сильно от других СУБД.
Журналы так же как и таблицы можно защищать не только на аппаратном уровне с помощью RAID, но и на уровне базы механизмом FALLBACK. Что повышает отказоустойчивость ситемы в целом.

Если мы делаем full backup, то таблицы на его время локируются. Что не есть хорошо, если нужно, чтобы таблицы были доступны 24х7.
В этом случае делается backup постоянного журнала, при этом таблица остаётся доступной. Можно делать backup одного или нескольких AMP. Для таблиц, в которых есть PARTITIONING можно делать бэкап отдельных партиций.
Бэкап также делается параллельно (как, собственно, и всё остальное, как Вы уже догадались :)

kmike
А нафига ему знать скорость вращения дисков? В DB2 для табличных пространств задаются 2 параметра, участвующих в расчёте стоимости: OVERHEAD и TRANSFERRATE, скорость процессора и пропускную способность сети оно тоже знает.


Немного неточно выразился. Извините.
Здесь более точно (сорри, форматировать некогда - спать охота):

External Cost Parameters
External cost parameters are various families of weights and measures,
including the parameters listed in the following table.
External Cost Parameter
Group
Definition
Optimizer weights and
scales
Weightings of CPU, disk, and network contributions to optimizing
a request plus scaling factors to normalize disk array and
instruction path length contributions.
Unitless decimal weighting factors.
CPU cost variables CPU costs for accessing, sorting, or building rows using various
methods.
Disk delay definitions Elapsed times for various disk I/O operations.
Measured in milliseconds.
Disk array throughput Throughputs for disk array I/O operations.
Measured in I/Os per second.
Network cost variables Message distribution and duplication costs and overheads.
Measured in milliseconds.
Optimizer
environment variables
Hardware configuration information such as the number of CPUs
and vprocs per node, maxima, minima, and average numbers of
MIPS per CPU, nodes per clique, disk arrays per clique, and so on.
Unitless decimal values.
Miscellaneous cost
parameters
DBSControl information such as free space percentages, maximum
number of parse tree segments, dictionary cache size, and so on.
Measured in various units, depending on the individual cost
parameter.
Performance constants Various values used to assist the Optimizer to determine the best
method of processing a given query.
Measured in various units, depending on the individual
performance constant.
PDE system control
files
Lists various system control files used by PDE. Used to initialize
the appropriate GDOs with the appropriate values at startup.
DBS control files Lists various database control files found in the DBSControl
record. Used to initialize the appropriate GDOs with their
respective appropriate values at startup.
TPA subsystem startup
initializations
Initializes or recalculates various Optimizer parameters, including
the optimizer target table GDO used by the target level emulation
software (see Chapter 6: “Target Level Emulation”).

kmike
Сейчас набегут борцы за снижение TCO и начнут кричать "single vendor lock-in!" и будут в чём-то правы :)
Опять тот же вопрос-какие преимущества даёт этот комплекс? Могу ли я для увеличения пропускной способности воткнуть Infiniband карточки в узлы? А по 7 штук в узел для обеспечения связи каждого узла с каждым в конфигурации из 8 узлов? Или проапгрейдить сеть на ещё более быструю?


Кстати, TCO Терадаты очень конкурентноспособный. В том числе и за счёт лёгкости в обслуживании.
По поводу пропускной способности - хотелось бы поддержжать Павла. Он правильную вещь говорит - система должна быть сбалансированной. Зачем дополнительная пропускная способность, если это не узкое место?
Связь каждый с каждым bynet и так поддерживает.
А в конфигурации из 85 узлов Вы инфинибанд будете в 84 экземплярах в узлы втыкать? :))


andrey_anonymous
Это не самая большая проблема. По крайней мере для оракеля.
Комбинаторика комбинаторикой, но построение плана требуется только при первом выполнении запроса. При этом оптимизатор ограничен во времени и действительно может не рассмотреть часть вариантов, однако и на эту проблему оракл предлагает решение: есть режим работы оптимизатора, в котором он просто генерирует планы, не думая о временных рамках.
Планы можуг быть сохранены для последующего использования и даже экспортированы на другую БД :)
Эвристика тоже имеет место, но релиз за релизом ее роль падает - она скорее мешает в нетривиальных случаях (вроде того, на который я давал забракованную Вами ссылку).


Про комбинаторику - предлагаю провести вычисления.
Соединить 10 таблиц теоретически можно количеством способов порядка 2*10^10. Допустим, СУБД способна оценить один план за 1 микросекунду (то есть за 10^-6 сек). Умножаем, получаем, что для того, чтобы оценить все способы понадобится 2000 секунд, то есть примерно 33 минуты. Полагаю, что в случае с 20 таблицами получится астрономический период времени.
Вот и вопрос - как тут без эвристик? Что-то нужно сразу отбросить, а нужно понимать, как.
По поводу сохранения планов - действительно, смешно. Интересно, а есть серьёзные СУБД, которые не умеют этого делать?



С уважением,
Константин Лисянский
http://lissianski.narod.ru
 
	    

        
27 окт 06, 01:21    [3317944]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
kmike
Member

Откуда:
Сообщений: 286
Константин Лисянский , поясните пожалуйста ваш постулат о том, что в Терадате нужно меньше индексов? За счёт чего это?

Про распределение ресурсов между клиентами-так это без этого сейчас никуда. В Оракле это делает Resource Manager, в DB2 - Query Patroller. Так что здесь Терадата не даёт ничего принципиально нового.

В списке переменных, учитываемых оптимизатором, тоже не вижу ничего выдающегося.
Константин Лисянский
Кстати, TCO Терадаты очень конкурентноспособный. В том числе и за счёт лёгкости в обслуживании.

Цифры есть?

Константин Лисянский
По поводу пропускной способности - хотелось бы поддержжать Павла. Он правильную вещь говорит - система должна быть сбалансированной. Зачем дополнительная пропускная способность, если это не узкое место?

А откуда уверенность, что оно узким местом не является? Пока что не было продемонстрировано, что Терадата может выполнить объединение таблиц по столбцам, не являющимся ключом хэш-секционирования, без их пересылки по сети.
Цитирую Teradata Magazine:
Many kinds of communication are required, including starting an operation on all nodes (e.g., scan all rows); coordinating the completion of an operation on all nodes (e.g., a join); redistributing a relation to prepare for a join; and coordinating the return of a result set, a portion of which exists on each node. Every one of these operations must be fully scalable for Teradata to deliver scalable performance to your applications.

Константин Лисянский

Связь каждый с каждым bynet и так поддерживает.

Да ну? В том же Teradata Magazine почему-то пишут
"The BYNET works like a phone switch, quite different from a typical network. Its switched "folded banyan" architecture".
Каждый с каждым-это вовсе не то же самое, что "Весь один сетевой адаптер каждого узла воткнут в один общий свитч".

Константин Лисянский

А в конфигурации из 85 узлов Вы инфинибанд будете в 84 экземплярах в узлы втыкать?

Нет, я выберу топологию, наиболее отвечающую моим требованиям. Fat tree, Flat Neighborhood Network, да хоть гиперкуб, если мне так будет удобно :)

В общем, по-прежнему не видно реальных преимуществ перед DB2 DPF.
Ну и хотелось бы ответов на остальные вопросы, ранее уже заданные.
27 окт 06, 06:35    [3318101]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД (Oracle, DB2, Microsoft SQL Server, MySQL)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Константин Лисянский
andrey_anonymous
Ну оно и логично - вариантов-то небогато, один узел=1 хеш-раздел.

Это довольноо далеко от истины. 1 узел = (65535 / количество узлов в системе) разделов (в терминах Терадаты hash bucket).
Я неудачно выразился. Имелось ввиду, что логика размещения по узлам в данном случае однозначна и может быть поручена роботу.
В shared disk размещение разделов - нескольк более "творческая" работа.
Константин Лисянский
andrey_anonymous
Если цель - parallel DML, то, скорее всего (не во всех случаях), да.
Если выборки - то правило не такое жесткое.
А не могли бы Вы пояснить какая между ними разница? Разве выборка - это не DML?
К DML обычно относят insert, update, delete - то есть операции, модифицирующие данные.
Константин Лисянский
Мне сложно понять, просто в Терадате параллелится всё без исключения.
В Oracle select может в parallel режиме сканировать несекционированную таблицу или один-единственный раздел. Update так не может, на мой взгляд, ввиду сложности процесса согласования этой деятельности (размещения блокировок).
Разумеется, различные разделы могут обрабатываться в parallel и этими операциями.
Константин Лисянский
Кстати, тут по ходу возникли вопросы по поводу параллелизма триггеров, UDF и хранимых процедур. Как с этим в Оракл?
Довольно неплохо.
deterministic UDF, будучи включенной в текст SQL-запроса просто выполняется в контексте одного из параллельных процессов, более сложные случаи вроде пользовательских аналитических/агрегатных функций или ковейерных функций (pipelined) требуют соблюдения определенных соглашений при написании и соответствующей декларации.
Однако сам по себе императивный код PL/SQL режима параллельного исполнения не имеет - только в контексте SQL.

Константин Лисянский
Кстати ещё про одно преимущество (оно косвенно объясняет и лучшее сопровождение) - в Терадате нужно гораздо меньше индексов и агрегатов.
Можно с этого места поподробнее - вроде как свежая мысль в контексте обсуждения...
Константин Лисянский
Бэкап также делается параллельно (как, собственно, и всё остальное, как Вы уже догадались :)

Лучше бы он делался в online :)
Константин Лисянский
andrey_anonymous
Комбинаторика комбинаторикой

Про комбинаторику - предлагаю провести вычисления.
Соединить 10 таблиц теоретически можно количеством способов порядка 2*10^10.
Вообще-то способов всего порядка 10!, что делает Вашу оценку завышенной почти в 5511.5 раз со всеми вытекающими :)
27 окт 06, 11:43    [3319428]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить