6 Предложение.

1. Выработать корпоративную стратегию развития, для определения способов консолидации и централизации.

2. Если централизация и консолидация будет предполагаться на основе регионов и/или департаментов, целесообразно использовать System P, базу данных DB2, для критической бизнес-логики TXSeries (CICS Family), для остальной WebSphere Application Server.

3. Для эффективного использования всех ресурсов и обеспечения наивысшего уровня качества предоставляемого сервиса ИТ услуг целесообразно применять System Z с использованием z/OS с максимальной степенью консолидации разных задач и централизации однотипных задач.

4. На переходном этапе к полной централизации целесообразно применять промежуточную консолидацию разных систем в System Z под управлением z/VM.

5. С целью максимальной утилизации возможностей, предоставляемых System Z, для обеспечения хранения и обработки критически важных данных в OLTP системах целесообразно применять IMS как в качестве архитектурного слоя хранения данных, так и в качестве слоя исполнения бизнес-логики по обработке данных.

6. Для реализации функций хранилища данных, OLAP систем, систем поддержки принятия решения, а также второстепенных по значению OLTP систем, не столь критичных к времени и качеству исполнения, уровням изоляции, целесообразно применять DB2, с аналитическими пакетами.

7. Для реализации и исполнения общей бизнес-логики целесообразно применять WebSphere Application Server, для построения и исполнения композитных бизнес-процессов — Process Server.

8. Для обеспечения отказоустойчивости и предотвращения недоступности систем целесообразно использования технологии Parallel Sysplex.

9. Для обеспечения катастрофоустойчивости целесообразно применения технологии GDPS — географически распределённого кластера.

10. Для обеспечения оптимальной загрузки System Z, уменьшения количества систем, и уменьшения затрат на интеграцию, целесообразно переносить на z/OS все доступные системы, добиваясь наилучшее соотношения между затратами на обслуживание систем, и количеством исполняемой работы.

11. Для снижения расходов и времени на программирования бизнес-логики целесообразно применять предлагаемые IBM высокоуровневые инструменты, такие как Rational Developer for System Z, язык EGL, инструменты управления, такие как IMS Explorer, средства организации и обеспечения жизненного цикла программного обеспечения.

7 Аппаратная реализация.

7.1 Переключение контекста в Z и других платформах.

При использовании виртуальной памяти особое значение имеют накладные расходы на переключение контекста адресного пространства. При этом виртуальную память делят на страницы относительно небольшого размера, например, в 4К. Обычно основой контекста являются две таблицы — таблица страниц, где хранится информация по расположению в реальной памяти виртуальных страниц, и таблица сегментов, более крупных фрагментов памяти, обычно объединяющих по 16–64 страниц. Скорость переключения контекста определяется тем, насколько быстро осуществляется загрузка в управляющие структуры процессора ссылок на таблицы страниц и сегментов того адресного пространства, которое должно стать активным. На других платформах это делается только для одного адресного пространства, и львиная доля работы осуществляется программно, так как единственная функция, возложенная на оборудование (в частности, на блок управления памяти MMU) при реализации виртуальной памяти состоит в трансляции адресов. На System Z уже начиная с архитектуры XA (это 1980-е годы) было 2 управляющих регистра, ссылающихся на отдельные наборы таблиц и сегментов, что позволяло без переключения контекста работать с двумя адресными пространствами. При этом переключение адресного пространства осуществлялось только сменой содержимого только управляющего регистра. В современной z/Architecture доступно 16 пар регистров доступа и управляющих, позволяющих одновременно, без переключения контекста процессора, выполнять 16 адресных пространств.

8 Программная реализация.

8.1 Циклы в разработке систем с использованием РСУБД.

1. Составление первоначальной структуры данных в РСУБД, составление запросов к данным для реализации бизнес-функций.

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

3. Появление неудовлетворительных по времени исполнения запросов, связанных с неоптимальными программами доступа к данным, генерируемыми оптимизатором.

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

5. Изменение в результате исследования:

• запросов на доступ к данным;

• структуры данных, к которым осуществляется доступ;

• поведение оптимизатора, применением к нему специальных инструкций;

• любому сочетанию предыдущих пунктов или всех вместе.

6. Изменение программ, использующих запросы доступа к данным, проведение циклов тестирования и сдачи в эксплуатацию.

7. Возвращаемся к пункту 2.

8.2 Накладные расходы РСУБД при обработке данных.

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

8.3 Аналитики о IMS.

InformationWeek.

IMS still retains one advantage: the speed of «hard-wired» simplicity. That gives it the benefit of moving clearly defined transactions at a rate of 22,000 per second, a rate relational systems can’t match.

IMS has been periodically upgraded because some of IBM’s largest customers continue to depend on it. Last year, the company brought out IMS 10 with better XML handling capabilities and the ability to execute XQuery-based queries to retrieve small amounts of specific XML data. XML forms are constructed in a hierarchical way that lends their data to being stored in a hierarchical database.

EbizQ.

With more than 95% of Fortune 1000 companies using IMS, and more than 200 Million IMS users per day, integration of IMS services as part of modern Service Oriented Architectures has already been embraced by hundreds of IMS clients. IMS 11 will also continue to raise the bar for availability and performance while reducing the resources needed to manage the system.

Network Computing.

«IMS Transaction Manager and Database Manager are our most reliable front-end systems for our highest critical applications. I am excited to hear about the upcoming new features and functions on IMS 11. This shows IBM’s commitment to a long (another 40 years) and successful future for IMS,» added Manuel Gomez, DBA Manager, Confederacion Espanola de Cajas de Ahorros (CECA), which represents 46 Spanish Savings Banks and provide services to 96.3% of the population across the entire nation.

Stephen Swoyer, Enterprise Systems, 11/06/2007.

«Pre-relational databases don’t die, nor do they fade away.» «While industry watchers such as Gartner Inc. once encouraged customers to think about transitioning away from pre-relational DMBs’s, they’re now backtracking. In a recent report, Feinberg said organizations should also do a thorough cost/benefit analysis before embarking on any such migration…the risks and additional costs entailed by migrating away from a pre-relational DBMS outstrip the costs.» «Odd though it may sound, there is no reason for IBM not to continue to refresh IMS with the latest technologies, to fit its users for integration into SOA and event-driven architectures of the future.»

Wayne Kernochan, Illuminata Perspectives, 10/19/2007.

«An ongoing I/T fear is that IMS experts will become thin. I believe that these fears are entirely overblown. One of the nicest features of IMS is its simplicity. Unlike object-oriented programming, IMS requires relatively little training for programming or administration. Big Blue has ample opportunity to keep on keeping on as far as IMS is concerned…» «Time and again, enterprises have found that migrating from an existing database to an enterprise-standard one involves extraordinary time, effort, and risk. Migrating may involve a multi-year rewrite of dependent business-critical applications, somehow without affecting the IT organization’s imperative to «keep the business running». Small wonder that IMS is one of the «tough nuts to crack» of today’s legacy modernization.»

Charles King, Principal analyst at Pund-IT.

«The new version of IMS is a great example of one of the things IBM does best: leverage its deep technical expertise to develop and deliver solutions for customers’ fundamental business challenges. In most large enterprises, heterogeneous I.T. infra-structures are the rule, not the exception.»

Curt Monash, database analyst.

« IMS is one of the fine things to stick with.»

8.4 Применение IMS в финасовом учёте.

В области финансового учёта с 1452 года и момента фиксации метода двойной записи в математическом труде Лука Пачоли, принципиальных изменений не произошло вплоть до нашего времени, и не предвидится даже в отдалённом будущем. Всё также существуют понятия счёт, баланс счёта, и операция проводки, как уменьшение баланса одного счёта и увеличение баланса другого, с соответствующими записями. И не важно, реализовано это в книге из пергамента, или в современном компьютере — набор базовых объектов и операций неизменен. Один раз реализованные базовые структуры данных и операции в IMS позволяют строить поверх них банковские, страховые, и любые другие продукты любой сложности с любой требуемой частотой. Дополнительным подтверждением этому могут служить множествo финансово-учётных систем, реализованных 40 лет назад на IMS, и на основе которых множество организаций, банков и страховых компаний, предлагают потребителям вновь создаваемые разнообразные продукты.

8.5 Изменение структуры в РСУБД.

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

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

8.6 Извлечение одних и тех же данных из РСУБД структуры и IMS структуры.

Рассмотрим простую структуру данных, информация о человеке, и информацию о его адресах, которых может быть несколько. Допустим, информация о человеке будет три поля — фамилия, имя, отчество — по 20 байт, информация о адресе — индекс 6 байт, населённый пункт 20 байт, улица 20 байт, дом 3 байта, квартира 3 байта. В РСУБД данная структура может быть представлена в виде двух таблиц, таблица ФИО и таблица адресов, при чём таблица адресов будет содержать ключ из таблицы ФИО. В IMS эта структура может быть представлена в виде иерархии из двух сегментов, в котором ФИО является родительским, адрес дочерним. Пусть у нас есть две записи в таблице ФИО и каждой из них соответствует две записи в таблице адресов.

8.6.1 Последовательность извлечения данных в РСУБД.

1. Составление SQL запроса, в котором происходит объединение двух таблиц на основе равенства ключей, выполняется программистом.

2. Оптимизатор строит план выполнения запроса, выбирая один из методов объединения таблиц, пусть это будет наиболее распространённый метод вложенных циклов.

• Берётся первая строка из таблицы ФИО, и производится сравнение ключевого поля записи с аналогичным ключевым полем первой записи таблицы адреса (скорее всего в реальной системе будет сравнение с ключевым полем индекса, построенном на таблице адреса, но суть от этого не меняется, сравнение будет выполнено, просто появляется дополнительная сущность — индекс — и дополнительные операции ввода-вывода), если поля не совпадают, строка пропускается, если совпадают — происходит формирование строки результирующего набора записей.

• Берётся следующая строка из таблицы ФИО, и производится сравнение, как в предыдущем пункте.

• После прохода всех строк таблицы ФИО результат возвращается программе-клиенту в табличном виде.

3. Программа-клиент выполняет вызов Fetch, и получает первую строку результирующего набора записей.

4. Программа-клиент продолжает вызывать Fetch для получения последующих строк из результирующего набора записей, в данном примере будет выполнено ещё три вызова Fetch.

5. При выполнении пятого вызова Fetch программа-клиент получит статус возврата, указывающий на отсутствие записей в результирующем наборе.

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

8.6.2 Последовательность извлечения данных из IMS.

1. Выполнение запроса, в котором указывается типы сегментов, которые необходимо вернуть — ФИО и адреса — и указывается тип операции — «Вернуть первый уникальный сегмент». После выполнения запроса в памяти программы-клиента находится первый сегмент ФИО в виде одной записи:

2. Выполнение запроса «Вернуть дочерний сегмент текущего родителя». Переход к дочернему сегменту выполняется IMS по ссылке, находящейся в префиксе найденного в предыдущем пункте сегмента. После выполнения запроса в памяти программы-клиента находится первый сегмент адреса в виде одной записи:

3. Повторение предыдущего запроса до получения всех сегментов адреса текущего человека, в данном случаев памяти программы будет находится второй сегмент адреса в виде одной записи:

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

4. При последующей попытке выполнения предыдущего запроса программа-клиент получит код возврата, означающий отсутствие искомого сегмента, после чего выполнит запрос «Вернуть следующий сегмент» с указанием параметров поиска из пункта . После выполнения запроса в памяти программы-клиента будет находится второй сегмент ФИО в виде одной записи:

5. Программа-клиент повторяет последовательность вызовов из пунктов и до получения статуса возврата, означающего отсутствие искомого сегмента, получая в память по одному сегменты адреса, соответственно

и

6. При последующей попытке выполнить запрос из пункта программа-клиент получит статус возврата, означающий отсутствие искомого клиента.

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