|
другу получать правильные результаты, что в свою очередь естественным образом сказывается на надёжности функционирования программного обеспечения. 2. Если заранее известен набор всех поступающих транзакций, то теоретически можно перебрать все возможные варианты графиков запусков (их конечное число, хотя и очень большое), и выбрать из них те графики, которые, во-первых, правильные, а во-вторых, оптимальны по выбранному критерию. Однако в реальной ситуации неизвестно не только какие транзакции будут поступать в какие моменты времени, но и неизвестна длительность периода времени, охватывающего набор транзакций. Т.к. транзакции не мешают друг другу, если они обращаются к разным данным или выполняются в разное время, то имеется два способа разрешить конкуренцию между поступающими в произвольные моменты транзакциями: • притормаживать" некоторые из поступающих транзакций настолько, насколько это необходимо для обеспечения правильности смеси транзакций в каждый момент времени (т.е. обеспечить, чтобы конкурирующие транзакции выполнялись в разное время). Данный алгоритм реализуется путем использованием блокировок различных видов или метода временных меток. • предоставить конкурирующим транзакциям "разные" экземпляры данных (т.е. обеспечить, чтобы конкурирующие транзакции работали с разными версиями данными). Данный алгоритм реализуется путем использованием данных из журнала транзакций. 3. Предложен ряд алгоритмов управления параллельными транзакциями: алгоритм работы планировщика основанный на временных метках, многоверсионный вариант двухфазного протокола синхронизации, многоверсионный протокол для транзакций, не изменяющих данные, а также MVSG планировщики. Однако их применение на практике оказывает влияние как на физическую, так и на логическую сторону организации многоверсионной СУБД. 73 |
Транзакция Тт={Т1т,Т2п1,Тз,1,,...)Тшпт }поступит в момент tm. В этом случае, т.к. набор всех транзакций заранее известен, теоретически можно перебрать все возможные варианты графиков запусков (их конечное число, хотя и очень большое), и выбрать из них те графики, которые, во-первых, правильные, а во-вторых, оптимальны по выбранному критерию. В этом случае оптимальный график запуска транзакций достижим. В реальной ситуации, однако, неизвестно не только какие транзакции будут поступать в какие моменты времени, но и неизвестна длительность периода времени, охватывающего набор транзакций. Реально, система может непрерывно работать несколько дней или месяцев и в этом случае набором транзакций будет набор всех транзакций за этот период. С другой стороны, прекращение работы сервера может произойти в любой момент либо по команде администратора системы, либо в результате сбоя. Необходимо, следовательно, чтобы система работала так, чтобы к любому моменту времени набор выполненных и выполняющихся в этот момент транзакций был бы правильным и не слишком далек от оптимального. Т.к. транзакции не мешают друг другу, если они обращаются к разным данным или выполняются в разное время, то имеется два способа разрешить конкуренцию между поступающими в произвольные моменты транзакциями: 1. "Притормаживать" некоторые из поступающих транзакций настолько, насколько это необходимо для обеспечения правильности смеси транзакций в каждый момент времени (т.е. обеспечить, чтобы конкурирующие транзакции выполнялись в разное время). 2. Предоставить конкурирующим транзакциям "разные" экземпляры данных (т.е. обеспечить, чтобы конкурирующие транзакции работали с разными версиями данными). Первый метод "притормаживание" транзакций реализуется путем использованием блокировок различных видов или метода временных меток. Второй метод предоставление разных версий данных реализуется путем использованием данных из журнала транзакций. проблем. Выделяют три основные проблемы: проблема потери результатов обновления, проблема незафиксированной зависимости (чтение "грязных" данных, неаккуратное считывание), проблема несовместимого анализа. Анализирование проблем параллелизма показывает, что если не предпринимать специальных мер, то при работе в смеси нарушается свойство (И) транзакций «изолированность». Транзакции реально мешают друг другу получать правильные результаты, что в свою очередь естественным образом сказывается на надёжности функционирования программного обеспечения. 2. Если заранее известен набор всех поступающих транзакций, то теоретически можно перебрать все возможные варианты графиков запусков (их конечное число, хотя и очень большое), и выбрать из них те графики, которые, во-первых, правильные, а во-вторых, оптимальны по выбранному критерию. Однако в реальной ситуации неизвестно не только какие транзакции будут поступать в какие моменты времени, но и неизвестна длительность периода времени, охватывающего набор транзакций. Т.к. транзакции не мешают друг другу, если они обращаются к разным данным или выполняются в разное время, то имеется два способа разрешить конкуренцию между поступающими в произвольные моменты транзакциями: • притормаживать" некоторые из поступающих транзакций настолько, насколько это необходимо для обеспечения правильности смеси транзакций в каждый момент времени (т.е. обеспечить, чтобы конкурирующие транзакции выполнялись в разное время). Данный алгоритм реализуется путем использованием блокировок различных видов или метода временных меток. • предоставить конкурирующим транзакциям "разные" экземпляры данных (т.е. обеспечить, чтобы конкурирующие транзакции работали с разными версиями данными). Данный алгоритм реализуется путем использованием данных из журнала транзакций. 3. Предложен ряд алгоритмов управления параллельными транзакциями: алгоритм работы планировщика основанный на временных метках, многоверсионный вариант двухфазного протокола синхронизации, многоверсионный протокол для транзакций, не изменяющих данные, а также MVSG планировщики. Однако их применение на практике оказывает влияние как на физическую, так и на логическую сторону организации многоверсионной СУБД. |