Клонирование и управление фрагментами базы данных

Клонирование и управление фрагментами базы данных

Иллюстрации

Показать все

Реферат

Предшествующий уровень техники

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

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

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

Сущность изобретения

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

Представленный пример обеспечивает механизмы и методы для клонирования и управления фрагментами базы данных. Объект базы данных, такой как таблица, набор строк, индекс или раздел таблицы или индекса, разделен на фрагменты. Отметим, что “набор строк” рассматривается как набор строк в таблице или элементов в индексе. Термины “строка” и “запись” рассматриваются как, по существу, идентичные. Таким образом, набор строк также эквивалентен набору записей. Каждый фрагмент клонируется для создания клонированных фрагментов, которые операционно, по существу, идентичны друг другу. Один из клонированных фрагментов может быть обозначен как первичный клонированный фрагмент для выполнения операций базы данных, а один или более клонированных фрагментов могут быть обозначены как вторичные клонированные фрагменты, служащие в качестве резерва для клона первичного фрагмента. Обновления для каждого фрагмента реализуются над первичным клонированным фрагментом и затем распространяются от первичного клонированного фрагмента к соответствующим вторичным клонированным фрагментам.

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

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

Описание чертежей

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

Фиг.1 - пример структуры клонирования данных объекта базы данных, управляемого системой базы данных.

Фиг.2 - пример клонированных фрагментов объекта базы данных.

Фиг.3 - пример операций для обновления клонированных фрагментов объекта базы данных.

Фиг.4 - пример операций для регенерации устаревшего клонированного фрагмента, ассоциированного с объектом базы данных.

Фиг.5 - пример структур данных для идентификации клонированного фрагмента.

Фиг.6 - пример структур данных для идентификации элемента в клонированном фрагменте объекта базы данных.

Фиг.7 - пример процессов для обновления вторичных клонированных фрагментов индекса и вторичных клонированных фрагментов данных.

Фиг.8 - развитие состояний при регенерации устаревшего клонированного фрагмента.

Фиг.9 - пример системы базы данных с клонированными фрагментами базы данных.

Фиг.10 - пример процесса для обновления объекта базы данных.

Фиг.11 - пример процесса регенерации, который регенерирует устаревший клонированный фрагмент объекта базы данных.

Фиг.12 - пример процесса для модифицирования идентификаторов обновления клона (CUID).

Фиг.13 - пример процесса для присвоения значения CUID, назначенного в соответствии с процессом, показанным на фиг.12.

Фиг.14 - пример путей распространения для значений CUID.

Фиг.15 - пример вычислительного устройства для реализации описанных систем и способов.

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

Фиг.17 - пример процесса для приведения устаревшего клона в текущее состояние как часть процесса регенерации, показанного на фиг.11.

Одинаковые ссылочные позиции используются для обозначения подобных элементов на приложенных чертежах.

Детальное описание

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

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

На фиг.1 представлен пример структуры 100 клонирования данных объекта 105 базы данных, управляемого системой базы данных. База данных является коллекцией информации, организованной таким способом, который позволяет быстро выбирать и/или обновлять желательные части данных в базе данных. Объект базы данных может быть всей базой данных или некоторой частью базы данных. Например, объект 105 базы данных может быть всей таблицей, индексом, набором строк или т.п.

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

Каждый раздел 111-113 объекта 105 базы данных (или весь, не разделенный объект 105) в типовом случае делится на фрагменты, такие как фрагменты 121-124. Фрагменты 121-124 являются частями объекта 105 базы данных, разделенными системой базы данных на операционной основе. Например, фрагменты 121-124 могут быть назначены различным вычислительным устройствам, так что запрос, ассоциированный с объектом 105 базы данных, может выполняться с фрагментами 121-124 вычислительными устройствами, работающими параллельно.

Фрагменты в объекте 105 базы данных далее клонируются для создания клонированных фрагментов. Как показано на фиг.1, каждый из логически разделенных фрагментов 121-124 клонируется для формирования примерных клонированных фрагментов 131, 140-146. В типовом случае, фрагменты объекта базы данных (или раздел объекта базы данных) создаются путем разбиения такого объекта на дискретные наборы строк (для таблиц) или элементы индекса (для индексов). Хеширование по ключу таблицы или индекса является одним основанием для выполнения такого разбиения. Наборы строк иногда упоминаются как “наборы строк” или “наборы записей”. Клонированные фрагменты будут обсуждены более детально в связи с фиг.2. Формулируя кратко, при надлежащем обновлении клонированные фрагменты, ассоциированные с конкретным фрагментом объекта 105 базы данных, операционно идентичны, так что клонированные фрагменты могут быть легко использованы системой базы данных. Использование клонированных фрагментов позволяет двум или более копиям конкретного фрагмента быть доступными для использования так, чтобы поддерживать высокий уровень доступности данных, ускорять запросы и другие операции базы данных, выполнять выравнивание нагрузки и т.п. Например, для поддержания высокого уровня доступности данных, по меньшей мере, один клонированный фрагмент может служить как резервная копия другого клонированного фрагмента, который используется для операций базы данных. Для ускорения поисков множество операционно идентичных клонированных фрагментов могут быть использованы одновременно для запросов базы данных. Для выполнения выравнивания нагрузки различные, но операционно идентичные копии клонированных фрагментов могут быть активированы, базируясь на условиях рабочей нагрузки.

На фиг.2 показаны приведенные для примера клонированные фрагменты 131-139 объекта базы данных. Как показано на этом чертеже, клонированные фрагменты 131-139 могут быть представлены как три группы 151-153. Каждая группа клонированных фрагментов относится к конкретному фрагменту объекта базы данных. Клонированные фрагменты внутри каждой группы создаются как операционно идентичные друг другу. Таким образом, при надлежащем обновлении каждый из клонированных фрагментов 131-139 может быть использован для операций базы данных, которые применимы для соответствующих фрагментов 151-153.

В одном варианте осуществления клонированные фрагменты 131-139 могут быть конфигурированы для обеспечения высокого уровня доступности данных. В этом варианте осуществления клонированный фрагмент из каждой из групп 151-153 может быть обозначен как первичный клонированный фрагмент для операций базы данных. Другие клонированные фрагменты в группе являются вторичными клонированными фрагментами, которые служат в качестве легко доступных резервных копий. На фиг.2 клонированные фрагменты 131, 135 и 139 показаны как первичные клонированные фрагменты, в то время как остальные клонированные фрагменты обозначены как вторичные клонированные фрагменты.

Для обеспечения высокого уровня доступности данных каждый из клонированных фрагментов в группе может быть включен в различные устройства, так что если одно устройство выходит из строя, вторичный клонированный фрагмент в другом устройстве может быстро заменить клонированный фрагмент в отказавшем устройстве в качестве первичного клонированного фрагмента. Например, каждый из клонированных фрагментов 131-133 может быть включен в отдельные устройства, так что любой из вторичных клонированных фрагментов 132-133 может быть указан как первичный, если устройство, в которое включен первичный клонированный фрагмент 131, вышло из строя.

Система базы данных, которая управляет клонированными фрагментами, может выполнять различные операции с клонированными фрагментами. Эти операции в типовом случае выполняются с использованием стандартных операций базы данных, таких как операторы языка управления (манипулирования) данными (DML) или операторы другого языка структурированных запросов (SQL). Примеры операций для обновления и регенерации клонированных фрагментов будут обсуждены более подробно ниже в связи с фиг.3 и 4. В одной примерной реализации операции могут включать следующее:

1. Создание клонированного фрагмента

Клонированный фрагмент может быть создан как неразличимый от нормальной таблицы или набора строк индекса в базе данных.

2. Удаление клонированного фрагмента

Клоны могут быть удалены подобно наборам строк в базе данных.

3. Полная инициализация данных клонированных фрагментов

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

4. Распространение изменений данных в клонированный фрагмент

Изменения для первичного клонированного фрагмента распространяются в один или более вторичных клонированных фрагментов. Распространение возникает внутри того же самого транзакционного контекста как обновления для первичного клонированного фрагмента.

5. Регенерация устаревшего клонированного фрагмента

Когда клонированный фрагмент был автономным или иным образом не принимал транзакционное распространение обновлений из первичного клонированного фрагмента, он определяется как устаревший клонированный фрагмент. Устаревшие клонированные фрагменты также могут быть определены как не обновленные (устарелые, несовременные) клоны фрагментов. Процесс возвращения устаревшего клона в транзакционное соответствие с клоном первичного фрагмента называется регенерацией (восстановлением).

6. Считывание клонированного фрагмента

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

7. Обновление клонированного фрагмента

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

Фиг.3 показывает примерные операции 300 для обновления клонированных фрагментов 131-139 объекта базы данных. Обновления базы данных могут включать в себя любые типы модификаций, такие как добавление, удаление и изменение данных. Если определены изменения, ассоциированные с объектом базы данных, то выявляются фрагменты в объекте базы данных, которые требуют обновления. Первичные клонированные фрагменты, соответствующие идентифицированным фрагментам, обновляются. Как показано на чертеже, операции 301-303 являются операциями для обновления первичных клонированных фрагментов 131, 135, 139, соответственно. После того как первичные клонированные фрагменты 131, 135 и 139 обновлены, обновления затем распространяются в соответствующие вторичные клонированные фрагменты. На фиг.3 операции 311-313 являются операциями для обновления вторичных клонированных фрагментов, соответствующих обновленным первичным клонированным фрагментам.

В типовом случае операции 301-303 и 311-313 реализуются посредством стандартных операций базы данных, таких как вставка, обновление и удаление, которые реализует семантика операторов DML. Чтобы достичь соответствия, операции по обновлению первичного клонированного фрагмента и операции по обновлению вторичных фрагментов, соответствующих первичному клонированному фрагменту, могут быть конфигурированы как элементарный набор операций.

Фиг.4 показывает примерные операции 400 для регенерации устаревшего клонированного фрагмента 133, ассоциированного с объектом базы данных. Клонированный фрагмент является устаревшим, если фрагмент был недоступен для исполнения операций распространенных обновлений, ассоциированных с объектом базы данных, соответствующим устаревшему фрагменту. Например, клонированный фрагмент 133 может быть недоступным для обновления ввиду различных причин, таких как отказ устройства, потеря связности, системное обновление и т.п. Для того чтобы быть полезным, вторичный клонированный фрагмент 133 должен быть возвращен в транзакционное соответствие с первичным клонированным фрагментом 131 с помощью процесса регенерации.

Когда клонированный фрагмент 133 возвращается в онлайновое состояние и становится доступным для исполнения операций обновления, клонированный фрагмент 133 регенерируется на основе данных, включенных в текущий первичный клонированный фрагмент, который содержит все текущие и прошлые обновления. Например, на фиг.4 операция 413 регенерации клона выполняется для регенерации клонированного фрагмента 133 данными, включенными в первичный клонированный фрагмент 131. Таким способом клонированный фрагмент 133 регенерируется с обновлениями, которые возникли в то время, когда клонированный фрагмент 133 был недоступным. Для эффективности, операция 413 регенерации клона может быть реализована посредством операций удаления SQL, которые удаляют устаревшие строки, и операций вставки SQL, которые добавляют новые строки, скопированные из первичного клона. Такая реализация обеспечивает возможность управления операцией регенерации по маршрутам исполнения, подобным тем, которые используются в обычных исполнениях операторов SQL в системе базы данных без добавления дополнительных процессов.

Операция 401 обновления для первичного клонированного фрагмента 131 возникает, когда обновление для объекта базы данных воздействует на часть объекта, соответствующую первичному клонированному фрагменту 131. Обновление затем распространяется к вторичным клонированным фрагментам, ассоциированным с первичным клонированным фрагментом 131. Как показано на фиг.4, вторичный клонированный фрагмент 132 обновляется операцией 411, ассоциированной с первичным клонированным фрагментом 131. Необходимость в обновлении клонированного фрагмента может возникнуть, когда клонированный фрагмент регенерируется. Например, обновление для клонированного фрагмента 133 может возникнуть, когда выполняется операция 413 регенерации клона. Операция 412 обновления может выполняться над клонированным фрагментом 133, в то время как выполняется операция 413 регенерации клона. В типовом случае, пользовательская операция 412 обновления является более высокоприоритетной операцией базы данных, чем операция 413 регенерации клона. Операция 412 обновления и операция 413 регенерации клона могут быть реализованы различными путями и с различным хронированием по отношению друг к другу. Например, если необходимо обновление, то операция 412 обновления над клонированным фрагментом 133 может быть завершена, прежде чем продолжится операция 413 регенерации клона. Кроме того, операция 413 регенерации клона проектируется для минимизации как частоты, так и продолжительности любой задержки, обусловленной вследствие блокирования по отношению к любой данной операции 412 обновления. Регенерация клона выполняется как последовательность малых транзакционных групп, которые требуют и удерживают блокировку только в течение коротких интервалов времени. Операция 412 обновляет только строки или элементы в устаревшем клоне, которые уже были регенерированы операцией 413 или которые остались неизменными в первичном клоне, пока устаревший клон был офлайновым. То есть, в операции 412 не допускается обновление строки, которая является несовременной в устаревшем клоне. Распространенной операции обновления не разрешается создавать несогласованную строку в устаревшем клоне, которая представляется требующей обновления. Это ограничение может быть смягчено в реализации, где вся строка распространяется с обновлением 412. Однако причины эффективности заставили бы отказаться от такой операции 412, которая распространяла бы целые строки для всех операций DML, независимо от того, что изменились только несколько значений столбцов. Введение новых, обновленных строк в устаревший клон является обязанностью операции 413 регенерации клона.

Операции 400 для регенерации устаревшего клонированного фрагмента, показанные на фиг.4, позволяют системе базы данных регенерировать устаревший клонированный фрагмент для обеспечения его транзакционной непротиворечивости с соответствующим первичным фрагментом, при поддержании онлайнового статуса того первичного фрагмента, с использованием стандартных операций базы данных. Использование стандартных операций базы данных, таких как представляющие операторы DML, позволяет управлять регенерацией клонов как дополнительной, но стандартной нагрузкой операторов SQL, не требуя специальных процессов. Операции 400 также обеспечивают регенерацию устаревшего клонированного фрагмента, не вызывая избыточного блокирования всего фрагмента и не требуя продления процесса регенерации, чтобы учесть обновления, которые могли возникнуть в течение процесса регенерации, поскольку эти обновления продолжают применяться в течение выполнения операции 413 регенерации. Важно, что операции 400 также позволяют эффективно обновлять вторичный клонированный фрагмент, чтобы быстро становиться готовым к выбору в качестве первичного клонированного фрагмента.

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

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

На фиг.5 показана примерная структура 511-514 данных для идентификации клонированного фрагмента 500. Структура 500 данных используется для идентификации клонированного фрагмента, соответствующего объекту базы данных. В этом примере структура данных идентифицирует клонированный фрагмент 500, который соответствует таблице, ассоциированной с базой данных. Как показано на фиг.5, идентификатор для клонированного фрагмента 500 может включать в себя идентификатор 511 таблицы, идентификатор 512 раздела, идентификатор 513 фрагмента и идентификатор 514 клона. Идентификатор 511 таблицы идентифицирует объект базы данных (таблицу в данном случае), которой соответствует клонированный фрагмент 500. Объект базы данных может быть разделен на разделы для разделения данных для удобства или по соображениям эффективности работы. Идентификатор 512 раздела идентифицирует разделы, которым соответствует клонированный фрагмент 500.

Система базы данных, которая управляет объектом базы данных, конфигурирована для автоматического разделения объекта базы данных на фрагменты и клонирования фрагментов. Идентификатор 513 фрагмента идентифицирует конкретный фрагмент объекта базы данных, которому соответствует клонированный фрагмент 500. Идентификатор 514 клона идентифицирует клонированный фрагмент 500 среди множества клонированных фрагментов, ассоциированных с конкретным фрагментом объекта базы данных.

На фиг.6 показана примерная структура 611-612 данных для идентификации записи 600 в клонированном фрагменте объекта базы данных. Клонированный фрагмент может включать в себя записи (или элементы индекса) базы данных. Например, клонированный фрагмент может включать в себя записи, воплощенные как строки в части таблицы, ассоциированной с базой данных. Структуры 611-612 данных в записи 600 обеспечивают возможность идентификации записи 600 в клонированном фрагменте и статуса обновления записи.

Как показано на фиг.6, запись 600 может включать в себя идентификатор 611 клонированной записи и идентификатор 612 обновления клона. Идентификатор 611 клонированной записи уникальным образом идентифицирует запись 600 в соответствующей таблице или индексе. Идентификаторы клонированных записей в записях индексов распространяются с обновлениями от соответствующих клонированных фрагментов данных. Определенный пользователем уникальный ключ может быть использован как идентификатор клонированной записи, или определенный системой уникальный ключ может быть добавлен (или усилен по отношению к определенному пользователем ключу), так что составной ключ является достаточно уникальным, чтобы служить в качестве идентификатора клонированной записи. Например, идентификатор фрагмента может быть добавлен к ключу в целях обеспечения дополнительной уникальности. Идентификатор обновления клона идентифицирует статус обновления записи 600. В этой примерной реализации идентификатор 611 клонированной записи должен быть уникальным в контексте данной таблицы. Идентификатор 612 обновления клона должен только уникальным образом идентифицировать статус обновления записи относительно статуса обновления других записей с тем же самым идентификатором 611 клонированной записи для данного объекта базы данных уникально во времени.

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

Процесс регенерации для устаревшего клонированного фрагмента использует идентификатор клонированной записи (CRID) и идентификатор обновления клона (CUID) для определения того, должна ли конкретная запись в клонированном фрагменте быть регенерирована. Например, запись в устаревшем клонированном фрагменте может включать в себя следующее:

CRID = x и CUID = y.

Соответствующая запись в первичном клонированном фрагменте, ассоциированном с устаревшим клонированным фрагментом, может включать в себя следующее:

CRID = x и CUID = z.

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

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

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

На фиг.7 показаны примеры процессов для обновления клонированных фрагментов индекса и клонированных фрагментов данных. Как описано выше, обновленный (или текущий) вторичный клонированный фрагмент фрагмента данных, по существу, идентичен первичному клонированному фрагменту для конкретного фрагмента данных. Аналогичным образом, обновленный вторичный клонированный фрагмент фрагмента индекса, по существу, идентичен первичному клонированному фрагменту для данного фрагмента индекса. Клонированные фрагменты индекса могут содержать элементы индекса, которые ссылаются на записи в более чем одном фрагменте данных. Следовательно, клонированные фрагменты индекса могут получать распространенные обновления более чем от одного клонированного фрагмента данных.

Пример на фиг.7 показывает фрагмент l1 индекса, содержащий элементы индекса, которые ссылаются на записи в двух отдельных фрагментах данных D1 и D2. В этом примере как первичный клонированный фрагмент l1.a 705 индекса, так и вторичный клонированный фрагмент l1.b 706 индекса получают распространенные обновления непосредственно как от первичного клонированного фрагмента D1.a 702 данных, так и от первичного клонированного фрагмента D2.a 703 данных.

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

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

В примерной реализации значения идентификатора обновления клона (CUID) могут поддерживаться на основе по каждой таблице. То есть, для оператора DML, который обновляет данный первичный клонированный фрагмент, значение CUID считывается из метаданных, специфических для соответствующей таблицы фрагмента. Записям, которые обновляются посредством того оператора, присваивается это значение CUID. Если обновления этих записей распространяются к вторичному клонированному фрагменту, то новые присвоенные значения CUID также распространяются.

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

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

Значения CUID для таблицы получают приращения каждый раз, когда фрагмент таблицы становится офлайновым. Эта реализация обсуждена ниже со ссылкой на фиг.12.

Также возможны другие стратегии назначения CUID, но каждая имеет возможность влияния на базовый метод для регенерации клона. Например, идентификаторы транзакции могут быть использованы в качестве базы для значений CUID, но требуют несколько менее предпочтительного метода регенерации клонов, чтобы гарантировать корректное взаимодействие распространения обновлений и регенерации клонов. Более конкретно, на этапе “ожидания распространения” (описан ниже), базовый метод “регенерации клона” должен ожидать завершения всех текущих активных транзакций вместо того, чтобы ожидать завершения выполнения всех текущих операторов DML.

В принципе, метод управления значениями CUID может быть реализован, если метод может удовлетворять следующим требованиям:

а) для данного значения CRID, используемого во фрагменте, все записи, идентифицированные этим значением CRID в транзакционно согласованных вторичных клонированных фрагментах, должны иметь знач