Тесты TPC

А.А. Волков

главный редактор, volkov@osp.ru

TPC-A
TPC-B
TPC-C

Одним из самых важных параметров СУБД является производительность. Измерение производительности сложных программных систем, к числу которых относятся и СУБД, само по себе является сложной задачей. Существует много подходов к ее решению. В статье рассказывается об одном из них - наборе тестов TPC (Transaction Processing Performance Council). Тесты TPC - TPC Benchmark A, TPC Benchmark B и TPC Benchmark C разработаны специально для определения производительности и стоимости сочетания программной и аппаратной платформ на задачах оперативной обработки транзакций (OLTP). Подавляющее большинство заказчиков при выборе платформ в качестве одного из критериев руководствуются показателями тестов TPC для этих платформ, выбирая производительность, необходимую для решения своих задач, и оптимальное соотношение цена/производительность. Что же стоит за этими цифрами?

Введение

Совет по Производительности Обработки Транзакций (TPC - Transaction Processing Performance Council) был образован при участии производителей средств вычислительной техники и программного обеспечения в конце 1988 года как независимый орган, устанавливающий стандарты для коммерческих эталонных тестов. В настоящий момент в Совет входит более 40 членов, среди которых все основные производители коммерческих компьютерных систем и баз данных.

Продукцией TPC является серия товарных знаков для спецификации эталонных тестов. Спонсоры эталонных тестов могут использовать товарный знак TPC в маркетинге своей продукции, только если они осуществляли тестирование своих продуктов в соответствии со специфицированными стандартами эталонных тестов и представили детальный, полностью открытый отчет наблюдателям из TPC, в число которых входят и представители их конкурентов - члены Совета. Эта группа опытных технических специалистов обеспечивает обязательный независимый аудит эталонных тестов. Именно она склонила TPC отвергнуть представленные на рассмотрение Совета многочисленные эталонные тесты как непригодные.

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

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

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

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

Сегодня доступны три эталонных теста: TPC-A, TPC-B и TPC-C. Сейчас завершается спецификация четвертого - TPC-D, предназначенного для тестирования систем поддержки принятия решений. К сожалению, у автора отсутствует подробная информация об этом тесте, поэтому дальнейшее изложение будет построено на трех уже специфицированных тестах - revision 1.2 для тестов TPC-A и TPC-B и revision 2.0 для теста TPC-C.

Краткое описание тестов

TPC-A

TPC-A - это простой эталонный тест, состоящий из одного приложения, при выполнении которого, правда, производится тестирование всех компонентов системы (включая терминалы пользователей и связующую сеть). При тестировании моделируется сеть банковских служащих, которые принимают депозиты и осуществляют выдачу вкладов. Клиенты обладают номером счета в банке и текущим балансом. В каждом филиале банка существует несколько кассиров, у каждого из которых есть некоторое количество наличных денег. Сумма всех наличных у всех кассиров составляет весь объем наличных денег в филиале. И наконец, банк хранит протокол всех операций. Количество филиалов, кассиров и счетов связаны следующими условиями :

• все филиалы должны иметь одно и то же количество кассиров;
• все филиалы должны иметь одно и то же количество счетов.

Диаграмма Сущности/Связи приведена на рис.1.

Логическая база данных состоит из четырех отношений: Account (Счет), Branch (Филиал), Teller (Кассир) и History (История).

При проведении теста TPC-A используется только одна транзакция. Описание этой транзакции на некотором псевдокоде следующее [1]:

Прочитать 100 байтов, содержащих Aid(идентификатор счета), 
        Tid(идентификатор кассира), Bid(идентификатор филиала), 
        Delta(сумма операции) с терминала пользователя 
BEGIN TRANSACTION 
Update Account where Account_ID = Aid: 
        Read Account_Balance from Account 
        Set Account_Balance = Account_Balance + Delta 
                Write Account_Balance to Account 
        Write to History: 
                Aid, Tid, Bid, Delta, Time_stamp 
        Update Teller where Teller_ID = Tid: 
                Set Teller_Balance = Teller_Balance + Delta 
                Write Teller_Balance to Teller 
        Update Branch where Branch_ID = Bid: 
                Set Branch_Balance = Branch_Balance + Delta 
                Write Branch Balance to Branch 
COMMIT TRANSACTION 
Вывести 200 байт, содержащих Aid, Tid, Bid, Delta,
        Account_Balance на терминал пользователя 

В цену тестируемой системы включается стоимость аппаратуры (вычислительная система, устройства вторичной памяти, сеть связи и терминалы пользователей), программного обеспечения, а также стоимость технического обслуживания аппаратных компонентов в течение пяти лет. Соотношение цена/производительность определяется как цена, отнесенная к максимальному числу зафиксированных транзакций в секунду (TPS-A) и выражается в тысячах долларов на TPS-A.

TPC-B

TPC-B предназначен для определения совместной производительности системы управления базами данных и аппаратной платформы, состоящей только из вычислительной системы и массовой памяти, на том же приложении, что и TPC-A.

Структура логической базы данных совпадает с аналогичной структурой TPC-A. Из определения транзакции изъяты части, производящие считывание информации с терминала пользователя и ее вывод обратно.

Производительность определяется как число зафиксированных транзакций в секунду (TPS-B), а соотношение цена/производительность вычисляется аналогично TPC-A.

TPC-C

Тест TPC-C осуществляет моделирование деятельности типичного склада. Такое моделирование представляет собой обработку смеси транзакций, в число которых входят транзакции, состоящие из нескольких операторов SQL. Некоторые из них включают агрегатные функции, неуникальные операторы select и соединение. Характерной чертой теста является также наличие асимметрии (т.е. неравновероятного доступа) в трех таблицах (в тестах TPC-A и TPC-B осуществляется равновероятный доступ). На рис.2

представлена иерархия коммерческих объектов, моделируемых тестом TPC-C. Этот рисунок воспроизведен из спецификации теста TPC-C [3]. База данных компании содержит информацию о нескольких складах. Каждый склад состоит из 10 участков, и каждый из участков имеет 3000 заказчиков. Существует 100000 наименований товаров, обслуживаемых каждым из складов. Уровень запасов для каждого из товаров, хранящихся на складах содержится в отношении Stock. Покупатели формируют заказы, информация о которых хранится в трех отношениях: в отношение Order помещается информация о каждом поступившем заказе; в отношении New-Order содержатся вновь поступившие заказы, и информация об этих заказах в дальнейшем удаляется из отношения транзакцией Delivery; в отношении Order-Line содержится информация о каждом товаре из заказанных. История операций оплаты добавляется к отношению History.

Таблица 1.

Логическая схема базы данных состоит из 9 отношений, перечисленных в таблице 1 и показанных на рис.3 (E/R - диаграмма для теста TPC-C). В таблице 1 W представляет число складов. Количество записей в отношениях Warehouse(Склад), District(Участок), Customer(Покупатель) и Stock(Запас) изменяется в зависимости от количества складов. Это похоже на тест TPC-A, где количество записей в отношениях Branch, Teller и Account зависит от количества филиалов. Число записей в отношении Item(Наименование товара) постоянно. Отношения Order(Заказ), Order-Line и History(История) растут неограниченно по мере обработки поступающих заказов.

В TPC-C используются транзакции пяти типов. Они перечислены в таблице 2. Транзакция New-Order(Новый-Заказ) обрабатывает поступивший на склад заказ, состоящий в среднем из 10 позиций, размещает информацию о заказе в базе данных и соответствующим образом обновляет уровень товарных запасов. Транзакция Payment(Платеж) обрабатывает платеж покупателя, обновляет его баланс и другие данные в отношениях Warehouse, District и Customer. Покупатель может быть идентифицирован либо уникальным идентификатором, либо по имени. Транзакция Order-Status(Статус-Заказа) возвращает статус последнего заказа покупателя. Так же как и в транзакции Payment, покупатель может быть указан, либо при помощи уникального идентификатора либо при помощи имени. Транзакция Delivery(Выполнение) обрабатывает 10 невыполненных заказов, по одному на каждый из участков, включающих 10 позиций. Соответствующие заказы удаляются из отношения New-Order. И наконец, транзакция Stock-Level(Уровень-Запасов) определяет количество товаров для элементов, заказанных в последних 20 заказах в участке.

Таблица 2.

Для более полного понимания операций, выполняемых каждой из транзакций, приведем их описания на некотором псевдокоде [4].

Транзакция New-Order

1. Select (whouse_id) from Warehouse
2. Select (dist_id, whouse_id) from District
3. Update (dist_id, whouse_id) in District
4. Select (customer_id, dist_id, whouse_id) from Customer
5. Insert into Order
6. Insert into New-Order
7. For each item (10 items)
   (a) Select (item_id) from Item
   (b) Select (item_id, whouse_id) from Stock
   (c) Update (item_id, whouse_id) in Stock
   (d) Insert into Order-Line
8. Commit

Транзакция Payment

Существуют две возможности. При первой из них (40% случаев) покупатель выбирается по своему идентификатору (customer_id). При второй (60% случаев) - по фамилии. Поскольку в среднем три покупателя имеют одну и ту же фамилию, производится сортировка по имени покупателя и выбирается средний из них.

1. Select (whouse_id) from Warehouse
2. Select (dist_id, whouse_id) from District
3. (a) Case 1: Select (customer_id, dist_id, whouse_id) from Customer
   (b) Case 2: Non-Unique-Select (customer_name, dist_id, whouse_id) from Customer
4. Update (whouse_id) in Warehouse
5. Update (dist_id, whouse_id) in District
6. Update (customer_id, dist_id, whouse_id) in Customer
7. Insert into History
8. Commit

Транзакция Order-Status

1. (a) Case 1: Select (customer_id, dist_id, whouse_id) from Customer
   (b) Case 2: Non-Unique-Select (customer_name, dist_id, whouse_id) from Customer
2. Select ( Max(order_id), customer_id) from Order
3. for each item in the order:
   (a) Select (order_id) from Order-Line
4. Commit

Обращение к базе данных _Select( Max(order_id), customer_id) from Order_ выбирает запись отношения Order, содержащую информацию о последнем заказе, размещенном покупателем. Это может быть реализовано с помощью агрегатной функции Max. Но поскольку отношение Order непрерывно растет, такой подход будет очень дорогостоящим. Реализацию такой возможности следует основывать на многоключевом индексе таким образом, чтобы необходимая запись могла быть найдена за один просмотр индекса.

Транзакция Delivery

1. Для каждого участка склада (т.е. 10 раз):
   (a) Select ( Min(order_id), whouse_id, dist_id) from New-Order
   (b) Delete (order_id) from New-Order
   (c) Select (order_id) from Order
   (d) Update (order_id) in Order
   (e) Для каждого пункта в заказе (т.е. 10 раз):
   i. Select (order_id) from Order-Line
   ii. Update (order_id) in Order-Line
   (f) Select (customer_id) from Customer
   (g) Update (customer-id) in Customer
2. Commit

Транзакция Stock-Level

Описание транзакции Stock-Level заимствовано из работы [3].

SELECT d_next_o_id INTO :o_id 
        FROM district 
        WHERE d_w_id = :w_id 
                AND d_id = :d_id; 
SELECT COUNT(DISTINCT(s_i_id)) 
        INTO :stock_count 
        FROM order_line, stock 
        WHERE ol_w_id = :w_id 
          AND ol_d_id = :d_id 
          AND ol_o_id :o_id 
          AND ol_o_id >= (:o_id - 20) 
          AND s_w_id = :w_id 
          AND s_i_id = ol_i_id 
          AND s_quantity < :threshold;

Формальные спецификации тестов

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

Спецификации тестов TPC-A и TPC-B состоят из 12 частей и приложения:

1. Преамбула.
2. Краткое описание транзакций и терминалов (только транзакций для TPC-B).
3. Свойства системы и транзакций.
4. Проектирование логической базы данных.
5. Правила масштабирования.
6. Распределение, разделение и выработка сообщений (выработка транзакций для TPC-B).
7. Время реакции (время выполнения для TPC-B).
8. Продолжительность теста.
9. Определение системы (SUT - System Under Test), управляющей системы (управляющая система (Driver System) - система, обеспечивающая эмуляцию удаленных терминалов - Remote Terminal Emulator - RTE) и коммуникаций (определение коммуникаций в тесте TPC-B отсутствует).
10. Методика определения стоимости.
11. Правила составления полного отчета о тестировании.
12. Аудит.

В приложении содержится пример реализации приложения на встроенном SQL.

Рассмотрим подробнее содержание преамбулы. Состав и предназначение других разделов спецификации будет приведен далее в описании спецификации теста TPC-C. Несмотря на то, что количество и структура разделов тестов TPC-A и TPC-B, с одной стороны, и TPC-C, с другой, несколько различаются, их предназначение и изложенные в них материалы очень похожи. Рассмотрение проведем, основываясь на спецификации теста TPC-A, поскольку, по мнению автора, этот тест является более употребительным.

Преамбула.

В преамбуле целью теста указывается тестирование компонентов систем, функционирующих в среде оперативной обработки транзакций (OLTP), причем подчеркивается, что особое внимание уделяется операциями со значительным числом операций обновления базы данных.

В качестве характерных элементов среды выполнения TPC-A в спецификации теста указаны:

• наличие множества подключенных терминалов;
• значительное количество дискового ввода/вывода;
• управляемое время выполнения системы и приложения;
• целостность транзакций.

В качестве характерных элементов среды выполнения TPC-B в спецификации теста указаны:

• значительное количество дискового ввода/вывода;
• управляемое время выполнения системы и приложения;
• целостность транзакций.

Тест TPC-A может быть выполнен как в глобальной (WAN), так и в локальной (LAN) сетевой среде. При этом никаких различий между результатами измерений не делается.

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

Структура спецификации теста TPC-C немного изменена. Спецификация состоит из 10 частей и трех приложений:

1. Преамбула.
2. Проектирование логической базы данных.
3. Краткое описание транзакций и терминалов.
4. Свойства системы и транзакций.
5. Правила масштабирования и объем базы данных.
6. Методика измерения производительности и время отклика системы.
7. Определение системы (SUT), управляющей системы и коммуникаций.
8. Методика подсчета стоимости.
9. Полный отчет.
10. Аудит.

Приложение A - Примеры реализации транзакций.

Приложение B - Формы для предоставления итоговых результатов теста.

Приложение C - Итоговые количественные характеристики.

Рассмотрим подробнее содержание и предназначение каждой из частей.

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

В качестве характерных элементов среды выполнения TPC-C в спецификации теста указаны:

• одновременное выполнение транзакций различных типов, значительно различающихся по своей сложности;
• выполнение транзакций как в оперативном так и в отложенном режиме;
• наличие множества подключенных терминалов;
• управляемое время выполнения системы и приложения;
• значительное количество дискового ввода/вывода;
• целостность транзакций (свойства ACID - atomicity, consistency, isolation, durability - атомарность, согласованность, изолированность, продолжительность);
• неравномерное распределение доступа к данным через первичные и вторичные ключи;
• многочисленные таблицы с широким набором размеров, атрибутов и связей;
• одновременное наличие операций выборки и обновления.

В качестве меры производительности, определяемой TPC-C, используется "коммерческая пропускная способность", отражающая количество обработанных в минуту заказов. При моделировании коммерческой деятельности при обработке заказа используется несколько транзакций, и для каждой из них указывается предельное время отклика. Мера производительности для этого теста выражена в транзакциях в минуту (transactions-per-minute-C - tpmC).

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

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

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

Краткое описание транзакций и терминалов. В начале раздела дается четкое определение всех терминов. Затем формулируются общие требования к терминальному вводу/выводу. После этого тщательно описываются все пять типов транзакций, входящих в состав теста.

Свойства системы и транзакций. Дается определение свойств ACID, приводятся требования к транзакциям теста, вытекающие из этих свойств. Описываются тесты, которые должны быть выполнены над транзакциями для гарантии выполнения свойств ACID.

Правила масштабирования и объем базы данных. В этом разделе определяются правила масштабирования системы. Основным параметром, по которому производится масштабирование, является количество складов. Размеры большинства отношений теста напрямую зависят от этого параметра. Кроме того, в разделе описывается, каким образом происходит рост объема базы данных с течением времени. В частности, указывается, что объема вторичной памяти должно быть достаточно для 180-дневной работы приложения теста.

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

Определение системы (SUT), управляющей системы и коммуникаций. Поскольку в тесте рассматриваются как системы LAN, так и WAN, а многообразие таких систем крайне велико, этому разделу в спецификации уделяется довольно большое внимание.

Методика подсчета стоимости. Очень важная часть спецификации. Определяется методология определения стоимости системы, стоимости сопровождения системы и приводятся требования для формирования результатов стоимости системы.

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

Аудит. Приводятся общие правила аудита. Кроме того, формулируется список тех проверок, которые должны быть выполнены аудитором для подтверждения правильности открытого отчета спонсора.

Структура приложений спецификации TPC-C была приведена ранее, и в качестве примера реализации одной из транзакций теста (New-Order) читатель может рассмотреть Пример 1, заимствованный в спецификации [3].

int neword() 
{ 
        EXEC SQL WHENEVER NOT FOUND GOTO sqlerr; 
        EXEC SQL WHENEVER SQLERROR GOTO sqlerr; 
        gettimestamp (datetime); 
        EXEC SQL SELECT c_discount, c_last, c_credit, w_tax 
                INTO :c_discount, :c_last, :c_credit, :w_tax 
                FROM customer, warehouse 
                WHERE w_id = :w_id 
                AND c_w_id = w_id 
                AND c_d_id = :d_id 
                AND c_id = :c_id; 
        EXEC SQL SELECT d_next_o_id, d_tax 
                 INTO :d_next_o_id, :d_tax 
                FROM district 
                WHERE d_id = :d_id 
                AND d_w_id = :w_id 
        EXEC SQL UPDATE district 
                SET d_next_o_id = :d_next_o_id + 1 
                WHERE d_id = :d_id 
                AND d_w_id = :w_id; 
        o_id = d_next_o_id; 
        EXEC SQL INSERT 
                INTO orders (o_id, o_d_id, o_w_id, o_c_id, 
                             o_entry_d, o_ol_cnt, o_all_local) 
                VALUES (:o_id, :d_id, :w_id, :c_id, :datetime,
                        :o_ol_cnt, :o_all_local); 
        EXEC SQL INSERT 
                INTO new_order (no_o_id, no_d_id, no_w_id) 
                VALUES (:o_id, :d_id, :w_id); 
        for (ol_number=1; ol_number<=o_ol_cnt; ol_number++) 
        { 
                ol_supply_w_id=atol(supware[ol_number-1]); 
                if (ol_supply_w_id != w_id) o_all_local=0; 
                ol_quantity=atol(qty[ol_number-1]); 
                EXEC SQL WHENEVER NOT FOUND GOTO invaliditem; 
                EXEC SQL SELECT i_price, i_name, i_data 
                        INTO :i_price, :i_name, :i_data 
                        FROM item 
                        WHERE i_id = :ol_i_id; 
                price[ol_number-1] = i_price; 
                strncpy(iname[ol_number-1], iname, 24); 
                EXEC SQL WHENEVER NOT FOUND GOTO sqlerr; 
                EXEC SQL SELECT s_quantity, s_data, 
                                s_dist_01, s_dist_02, 
                                s_dist_03, s_dist_04, 
                                s_dist_05, s_dist_06, 
                                s_dist_07, s_dist_08, 
                                s_dist_09, s_dist_10 
                        INTO :s_quantity, :s_data, 
                                :s_dist_01, :s_dist_02, 
                                :s_dist_03, :s_dist_04, 
                                :s_dist_05, :s_dist_06, 
                                :s_dist_07, :s_dist_08, 
                                :s_dist_09, :s_dist_10 
                        FROM stock 
                        WHERE s_i_id = :ol_i_id 
                        AND s_w_id = :ol_supply_w_id; 
                pick_dist_info(ol_dist_info, ol_w_id); 
                       // выбор необходимого s_dist_xx 
                stock[ol_number-1] = s_quantity; 
                if ((strstr(i_data, _начальный_) != NULL) 
                    && (strstr(s_data, _начальный_) != NULL))
                bg[ol_number-1] = "B"; 
                else 
                bg[ol_number-1] = "G"; 
        if (s_quantity > ol_quantity) 
                s_quantity = s_quantity - ol_quantity; 
        else 
                s_quantity = s_quantity - ol_quantity + 91; 
        EXEC SQL UPDATE stock 
                SET s_quantity = :s_quantity 
                WHERE s_i_id = :ol_i_id 
                AND s_w_id = :ol_supply_w_id; 
        ol_amount = ol_quantity * i_price * 
                   (1+w_tax+d_tax) * (1-c_discount); 
        amt[ol_number-1]=ol_amount; 
        total += ol_amount; 
        EXEC SQL INSERT 
                INTO order_line (ol_o_id, ol_d_id, 
                        ol_w_id, ol_number, ol_i_id, ol_supply_w_id, 
                        ol_quantity, ol_amount, ol_dist_info) 
                VALUES (:o_id, :d_id, :w_id, :ol_number, 
                        :ol_i_id, :ol_supply_w_id, 
                        :ol_quantity, :ol_amount, :ol_dist_info); 
        } 
        EXEC SQL COMMIT WORK; 
        return(0); 
invaliditem: 
        EXEC SQL ROLLBACK WORK; 
        printf(_Номер товара неверен_); 
        return(0); 
sqlerr: 
        error(); 
}

Пример 1.

Заключение

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

Для получения подробной информации о тестах можно обратиться непосредственно в TPC (Сан-Хосе, Калифорния, тел. 408-295-8894, факс 408-295-9768).

Литература

1. TPC Benchmark A, Standard Specification, revision 1.2, Transaction Processing Performance Council, March 16, 1993.
2. TPC Benchmark B, Standard Specification, revision 1.2, Transaction Processing Performance Council, March 16, 1993.
3. TPC Benchmark C, Standard Specification, revision 2.0, Transaction Processing Performance Council, October 20, 1993.
4. Leutenegger, S., Dias, D., "A Modelling Study of the TPC-C Benchmark", Proceedings of the 1993 ACM SIGMOD International Conference on Management of Data, May, 1993.
5. Kohler, W., Shah, A., Raab, F., "Overview of TPC Benchmark C: The Order-Entry Benchmark", technical report, Transaction Processing Performance Council, December 23, 1991.
6. Gray, J., (Editor), "The Benchmark Handbook for Database and Transaction Processing Systems", Morgan Kaufmann, 1991.