Файловые таблицы ms sql

Файловые таблицы ms sql

Изучение задач, связанных с программированием баз данных на платформе MS SQL Server.

Страницы

Страницы

четверг, 17 июля 2014 г.

Файловые таблицы

В Microsoft SQL Server 2012 появился новый вид таблиц: файловые таблицы. Эта технология расширяет существующую с 2008-ого года технологию filestream и предоставляет еще большую интеграцию между СУДБ MS SQL Server и файловой системой.
Что же такое файловая таблица? По сути дела такой таблице соответствует отдельная директория. Программа может просто обычным способом скопировать в эту директорию файл или каталог с другими файлами. При этом СУБД перехватит все вызовы по открытию и закрытию файлов и синхронизирует эти операции с таблицей. То есть, если скопировать в директорию файл и сразу сделать запрос к таблице, то запрос возвратит строку с новым файлом. То же самое относится и к операциям обновления и удаления файлов. Этот принцип действует и в обратную сторону: в таблицу можно вставлять записи, обновлять и удалять их, что инициирует соответствующие операции над файлами директории. При этом с файловыми таблицами можно (с небольшими ограничениями) работать как с обычными таблицами. Рассмотрим более подробно все эти операции на примере.
Сначала требуется включить технологию filestream на уровне сервера. Инструкция о том, как это сделать имеется в одной из моих предыдущих работ: Файловые потоки. Создадим базу данных:
create database FileTablesWrk

В базе данных должна быть файловая группа filestream:

alter database FileTablesWrk add file
( name = FilesStore , filename = ‘C:UsersedynakDesktopFiles’ ) to filegroup FilesWrk

Теперь необходимо задать директорию, которая будет хранить данные файловых таблиц для новой базы данных. Также требуется указать тип доступа к ней:
alter database FileTablesWrk set filestream
( directory_name = ‘FilesCont’ , non_transacted_access = full )

В этом коде, помимо директории задана возможность нетранзакционного доступа. То есть можно просто создавать, обновлять, удалять файлы и папки в директории FilesCont, и эти операции будут синхронизированы с таблицей. В качестве опции можно использовать значение read_only для нетранзакционного доступа только на чтение. Или off. В последнем случае доступ возможен только на стороне сервера через Transact-SQL или через потоковый доступ с помощью SqlFileStream, а сами файлы будут невидимы в директории FilesCont. С помощью вышеприведенного кода можно менять имя директории и тип нетранзакционного доступа в процессе работы в зависимости от потребностей. Например, для обеспечения полной транзакционной целостности можно отключить нетранзакционый доступ и работать средствами T-SQL, а там, где важна высокая скорость и экономия буферного пула — использовать потоковый доступ через класс SqlFileStream. Если же нужна еще большая скорость вставки и приемлем риск того, что при аварийном завершении копирования результаты вставки могут не полностью откатиться, то можно использовать нетранзакционный доступ.
Полное имя директории FilesCont: // / /FilesCont, где — это имя компьютера, а это имя общей папки, которая выбирается при настройке доступа к filestream на уровне сервера. Чтобы получить это имя можно выполнить такой запрос: select filetablerootpath () . Этот путь на самом деле логический. Физический путь отличается. Логический путь преобразуется в физический драйвером фильтра filestream.
Когда база данных настроена на использование файловых таблиц можно проверить ее настройки, сделав такой запрос:

where database_id = db_id ( ‘FileTablesWrk’ )

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

Здесь Data1 это директория, которая содержится в директории FilesCont. Указываются также параметры сортировки для содержимого таблицы. Список файловых таблиц можно посмотреть с помощью запроса:

from sys . filetables

Когда таблица создана, к ней можно сделать запрос и посмотреть на столбцы. Есть столбец file_stream типа varbinary ( max ), содержащий содержимое файла. Столбец name это имя файла. Столбец file_type — расширение, его можно использовать для полнотекстового индексирования; is_directory — это признак директории. Если в папке Data1 есть вложенные папки, то с помощью столбцов path_locator и parent_path_locator можно определить в какой директории находится файл. Можно сделать вставку строки в таблицу средствами Transact-SQL:

values ( ‘test.txt’ , cast ( ‘www’ as varbinary ( max ) ) )

Можно сделать запрос и убедиться, что строка вставлена:

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

Традиционным способом хранения в БД неструктурированных двоичных файлов, таких как видео, аудио, картинки и т. п. является определение в таблице поля типа varbinary(max) или применение FILESTREAM, появившегося в SQL Server 2008. В этой статье будет рассмотрен новый подход с использованием таблиц FileTable, которые появились в SQL Server 2012. Технология FileTable основывается на функционале FileStream, при этом расширяя его возможности. В FileTable для организации структуры каталогов используется тип HierarchyId, о котором вы можете прочитать в моей предыдущей статье.

Настройка сервера для поддержки FileTable

Для корректной работы FileTable сначала необходимо произвести настройку SQL Server. В первую очередь нужно включить поддержку FileStream на уровне сервера. Это можно сделать через SQL Server Configuration Manager. Перейдите в меню
Пуск > Все программы > Microsoft SQL Server 2012 > Configuration Tools > SQL Server Configuration Manager. Далее в левой панели выберите SQL Server Services, при этом в правой панели откроются все службы SQL Server. Выберите экземпляр SQL Server, на котором нужно включить поддержку FileStream, и перейдите в «Свойства» (рис. 1).

Рис. 1. Выбор экземпляра SQL Server, на котором необходимо включить поддержку FileStream

В окне свойств перейдите на вкладку FILESTREAM. Чтобы включить поддержку FileStream на сервере, отметьте флаг «Enable FILESTREAM for Transact-SQL access». Если вы хотите иметь возможность доступа к FileStream из файловой системы Windows, то отметьте флаг «Enable FILESTREAM for file I/O streaming access». Также здесь вы можете задать имя общей папки Windows для данных FileStream. Если нужно, чтобы удалённые клиенты могли иметь доступ к данным FileSteam, хранящимся в общей папке, то отметьте флаг «Allow remote clients to have streaming access to FILESTREAM data» (рис. 2). Все эти настройки можно также произвести при установке SQL Server.

Рис. 2. Включение поддержки FILESTREAM в SQL Server Configuration Manager

Далее откройте SQL Server Management Studio, зайдите в свойства сервера, перейдите на вкладку Advanced и в поле FileStream Access Level выберите «Full access enabled», как показано на рис. 3.

Рис. 3. Включение поддержки FILESTREAM в SQL Server Management Studio

Это также можно сделать с помощью скрипта, приведённого ниже:

Читайте также:  Как зарядить телефон от внешнего аккумулятора

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

Рис. 4. Создание файловой группы для поддержки FileStream

Затем перейдите на вкладку General и создайте файл, как показано на рис. 5. Тип данных установите в значение «FILESTREAM Data». В поле Filegroup выберите ранее созданную файловую группу. Также в поле Path задайте путь для хранения данных FileStream, например, c:FileTableDemoData . Этот путь должен существовать в файловой системе.

Рис. 5. Создание файла базы данных для поддержки FileStream

Теперь перейдите на вкладку Options. В разделе FILESTREAM в поле FILESTREAM Directory Name задайте имя директории. Эта директория будет создана в общей папке сервера, которая была задана при включении FileStream, а в неё, в свою очередь, будут помещаться папки для каждой таблицы FileTable, созданной в этой базе данных. Также, если вы хотите иметь доступ к файлам, хранящимся в FileTables, из файловой системы, необходимо установить нетранзакционный доступ, выбрав в поле FILESTREAM Non-Transacted Access значение «Full» (рис. 6).

Рис. 6. Настройка нетранзакционного доступа и имени директории для FileTables

Все эти действия можно сделать с помощью следующего скрипта:

Создание таблицы FileTable

Таблица FileTable является специализированной пользовательской таблицей с заранее заданной и фиксированной схемой, поэтому при её создании нет необходимости указывать список столбцов. Синтаксис для создания такой таблицы выглядит следующим образом:

FILETABLE_DIRECTORY — это корневой каталог для всех файлов и каталогов, хранящихся в FileTable. Если при создании не указано имя каталога, то в качестве него используется имя самой таблицы.
FILETABLE_COLLATE_FILENAME указывает имя параметров сортировки, применяемых к столбцу Name в таблице FileTable. Если значение не указано или задано как database_default, столбец унаследует параметры сортировки текущей базы данных.
С учётом вышесказанного, синтаксис создания FileTable может быть упрощён до следующего:

После создания FileTable перейдите к базе данных, раскройте узел FileTables и затем раскройте список столбцов созданной таблицы. Вы увидите структуру, показанную на рис. 7.

Рис. 7. Структура таблицы FileTable

В таблице хранится большинство атрибутов файла, а также его имя, размер, тип и родительский католог. Для указания каталогов существует флаг is_directory. В таблицы такого типа нельзя добавлять новые пользовательские столбцы, а также удалять или изменять существующие, но можно создавать пользовательские индексы, триггеры или ограничения.
После проделанных операций вы можете посмотреть структуру папок, которые создал SQL Server. В директории c:FileTableDemoData была создана папка FileTableDemo_FileStream. Все данные FileStream будут сохраняться в этой папке. Сейчас, если вы перейдёте в неё, то увидите там файл filestream.hdr и две директории (рис. 8). Они нужны для корректной работы FileStream и не должны удаляться или модифицироваться вручную.

Рис. 8. Папка, созданная SQL Server для хранения данных FileStream

Также вы можете перейти в общую сетевую папку, созданную SQL Server. В обобщённом виде путь к этой папке выглядит следующим образом: SERVERNAMEFILESTREAM_WINDOWS_SHARE_NAMEFILESTREAM_TABLE_NAME FILETABLE_DIRECTORY .
В нашем случае это будет выглядеть так: ServerSqlServer2012ExpFileTableDemoFiles .
В эту директорию можно попасть и с помощью SQL Server Management Studio. Для этого кликните правой кнопкой на созданной таблице FileTable и выберите пункт Explore FileTable Directory (рис. 9) Для доступа к директории FileTable требуются соответствующие разрешения SQL Server для таблицы. Если у пользователя нет таких разрешений, то доступ к этой папке из файловой системы будет запрещен.

Рис. 9. Доступ к папке FileTable из SQL Server Management Studio

В настоящий момент эта директория пуста. Вы можете помещать в неё файлы и папки обычным копированием, как показано на рис. 10.

Рис. 10. Копирование файлов в папку FileTable через файловую систему

Теперь сделаем выборку из нашей таблицы с помощью обычного скрипта:

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

Рис. 11. Выборка файлов из таблицы FileTable

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

Рабта с каталогами и путями в таблицах FileTable

Для работы с каталогами и путями таблиц FileTables существуют 3 функции:

  • FileTableRootPath([ ], [ ]) — получает корневой путь для конкретной таблицы FileTable или для текущей базы данных. Первый параметр — это имя таблицы FileTable, для которой необходимо вернуть путь. Он является необязательным, значение по умолчанию — это текущая база данных. Второй параметр — это целочисленное выражение, определяющее способ форматирования серверных компонентов пути. Использование этой функции приведено на рис. 12.

Рис. 12. Пример функции FileTableRootPath

  • .GetFileNamespacePath([ ], [ ]) — возвращает путь к файлу или каталогу в таблице FileTable. — это имя столбца file_stream типа varbinary(max) в таблице FileTable. — это целочисленное выражение, указывающее, какой путь возвращать — относительный или абсолютный. Он является необязательным, и по умолчанию выводится относительный путь внутри каталога уровня базы данных. Параметр аналогичен одноимённому параметру в пункте выше. Использование этой функции приведено на рис. 13.

Рис. 13. Пример функции GetFileNamespacePath

  • GetPathLocator( ) — возвращает значение идентификатора path_locator для заданного файла или каталога в таблице FileTable. — это путь к пространству имен в FileTable. Он имеет тип nvarchar(max). Использование этой функции приведено на рис. 14.

Рис. 14. Пример функции GetPathLocator

Преимущества использования FileTable

Особенность FileTables заключается в том, что эта технология объединяет компонент SQL Server Database Engine с файловой системой NTFS, размещая данные больших двоичных объектов (BLOB) типа varbinary(max) в файловой системе. Исходя из этого, можно выделить следующие преимущества:

  • возможен нетранзакционный доступ через файловую систему Windows, при этом производительность равняется производительности файловой системы;
  • для кэширования файлов в хранилище FileTable используется системный кэш NT, при этом SQL-буфер используется только для обработки запросов;
  • размер двоичного файла ограничен только размером NTFS-раздела;
  • возможен также транзакционный доступ с помощью обычных инструкций SELECT, INSERT, UPDATE и DELETE;
  • доступно использование интегрированных служб SQL Server, таких как резервное копирование, встроенная поддержка безопасности, полнотекстовый поиск и т. д.

Секционирование («партицирование») в SQL Server, при кажущейся простоте («да чего там – размазываешь таблицу и индексы по файловым группам, получаешь профит в администрировании и производительности») – достаточно обширная тема. Ниже я попробую описать как создать и применить функцию и схему секционирования и с какими проблемами можно столкнуться. О преимуществах я говорить не буду, кроме одного — переключение секций, когда вы моментально убираете из таблицы огромный набор данных, либо наоборот — моментально загружаете в таблицу не менее огромный набор.

Читайте также:  Синхронизация айфона с телевизором самсунг

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

Там же перечислены основные преимущества:

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

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

Поговорим о стопроцентном преимуществе, которое вы однозначно получаете вместе с секционированием (но которым тоже нужно суметь воспользоваться) – это гарантированное повышение удобства управления вашей БД. Например, у вас есть таблица с миллиардом записей, из которых 900 миллионов относятся к старым («закрытым») периодам и используются только для чтения. С помощью секционирования вы можете вынести эти старые данные в отдельную файловую группу только для чтения, забэкапить её и больше не тащить их во все свои ежедневные бэкапы – скорость создания резервной копии возрастёт, а размер уменьшится. Вы можете перестраивать индекс не по всей таблице, а по выбранным секциям. Кроме того, вырастает доступность вашей БД – если одно из устройств, содержащих файловую группу с секцией, выйдет из строя, остальные будут по-прежнему доступны.

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

Во-первых, создадим базу с 4 файловыми группами, в которой будем проводить эксперименты:

Создадим таблицу, которую будем мучать.

И заполним её данными за один год:

Теперь таблица pTest содержит по одной записи за каждый час 2018-го года.

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

Мы будем секционировать нашу таблицу по столбцу dt (datetime) таким образом, чтобы каждая секция содержала в себе данные за 4 месяца (тут я облажался — на самом деле первая секция будет содержать данные за 3, вторая за 4, третья за 5 месяцев, но для целей демонстрации — это не проблема)

Вроде бы всё нормально, но здесь я сознательно допустил одну «ошибку». Если посмотреть синтаксис в msdn, то вы увидите, что при создании можно указывать к какой секции будет относиться указанная граница – к левой, или к правой. По умолчанию, по какой-то неведомой причине, указанная граница относится к «левой» секции, поэтому для моего случая корректно было бы создать функцию секционирования следующим образом:

В то время, как я, фактически, выполнил:

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

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

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

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

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

Таким образом, мы получили три не очень удачные секции – первая хранит данные с начала времён по 01.04.2018 00:00:00 включительно, вторая – с 01.04.2018 00:00:01 по 01.08.2018 00:00:00 включительно, третья с 01.08.2018 00:00:01 до конца света (доли секунд я сознательно упустил, потому что не помню с какой градацией SQL Server записывает эти доли, но смысл передан верно).
Теперь создадим некластерный индекс по полю dummy_int, «выровненный» по той же схеме секционирования.

И посмотрим, почему я говорил, что ваши запросы могут стать медленнее, после внедрения секционирования. Выполним запрос:

И посмотрим статистику выполнения:

И план выполнения:

Поскольку наш индекс «выровнен» по секциям, условно, на каждой секции создан свой собственный индекс, «не связанный» с индексами на других секциях. Условий на поле, по которому секционирован индекс, мы не наложили, поэтому SQL Server вынужден выполнять Index Seek в каждой секции, фактически, 3 Index Seek вместо одного.

Давайте попробуем исключить одну секцию:

И посмотрим статистику выполнения:

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

Некластерный индекс нам больше не нужен, поэтому я его удаляю

Теперь рассмотрим следующий сценарий: данные из этой таблицы мы каждые 4 месяца архивируем – убираем старые данные и добавляем секцию для следующих четырёх месяцев (организация «скользящего окна» описана в msdn и куче блогов).

Разобьём задачу на мелкие и понятные подзадачи:

  1. Добавим секцию для данных с 01.01.2019 по 01.04.2019
  2. Создадим пустую stage-таблицу
  3. Переключим секцию с данными до 01.04.2018 в stage-таблицу
  4. Избавимся от пустой секции
Читайте также:  Изменение размера разделов жесткого диска windows 7

Поехали:

1. Объявляем, что новая секция будет создана в файловой группе FG1, потому что она у нас скоро освободится:

И меняем функцию секционирования, добавляя новую границу:

Всего в таблице (кластерном индексе) 8809 страниц, так что количество чтений, конечно, за гранью добра и зла. Посмотрим, что у нас теперь есть по секциям.

В целом, всё как и ожидалось – появилась новая секция с верхней границей (помните, что граничные условия у нас относятся к левой секции) 01.01.2019 и пустая секция, в которой будут остальные данные, у которых дата больше.

Вроде бы всё нормально, но почему так много чтений? Посмотрим внимательно на рисунок выше, и увидим, что данные из третьей секция, которые были в FG3 оказались в FG1, а вот следующая секция, пустая, в FG3.

2. Создаём stage-таблицу.

Для переключения (switch) секции в таблицу и обратно, нам требуется пустая таблица, в которой созданы все те же ограничения и индексы, что и на нашей секционированной таблице. Таблица должна быть в той же файловой группе, что и секция, которую мы хотим туда «переключить». Первая (архивная) секция лежит в FG1, поэтому создаём таблицу и кластерный индекс там же:

Секционировать эту таблицу не нужно.

3. Теперь мы готовы к переключению:

И вот, что мы получаем:

Забавно, посмотрим, что у нас в индексах:

Помните, я писал, что нужно было делать уникальный кластерный индекс на секционированной таблице? Вот именно поэтому и нужно было. При создании уникального кластерного индекса, SQL Server потребовал бы явного включения столбца, по которому мы секционируем таблицу, в индекс, а так он добавил его сам и забыл сказать об этом. И я правда не понимаю почему так.
Но, в общем, проблема понятна, пересоздаём кластерный индекс на stage-таблице.

И теперь ещё раз пробуем выполнить переключение секции:

Та-дам! Секция переключена, смотрим чего нам это стоило:

А ничего. Переключение секции в пустую таблицу и наоборот (полной таблицы в пустую секцию) – это операция исключительно над метаданными и это именно то, из-за чего секционирование — это очень и очень крутая штука.

Посмотрим, что там с нашими секциями:

А с ними всё здорово. В первой секции осталось ноль записей, они благополучно уехали в таблицу stageTest. Можем двигаться дальше

4. Всё, что нам осталось – это удалить нашу пустую первую секцию. Выполним и посмотрим, что произойдёт:

И это тоже операция только над метаданными, в нашем случае. Смотрим на секции:

У нас осталось, как и было, всего 3 секции, каждая в своей файловой группе. Миссия выполнена. Что можно было бы тут улучшить? Ну, во-первых, хотелось бы, чтобы граничные значения относились к «правым» секциям, чтобы секции содержали все данные за 4 месяца. И хотелось бы, чтобы создание новой секции обходилось меньшей кровью. Читать данных в десять раз больше, чем сама таблица – перебор.

С первым мы сделать сейчас ничего не можем, а вот со вторым – попробуем. Создадим новую секцию, которая будет содержать данные с 01.01.2019 по 01.04.2019, а не до конца времён:

Ха! То есть теперь это операция только над метаданными? Да, если вы «делите» пустую секцию – это операция только над метаданными, поэтому правильным решением будет держать и слева, и справа по гарантированно пустой секции и при необходимости выделения новой – «вырезать» их оттуда.

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

  1. Создать новую секцию слева для данных
  2. Переключить (switch) таблицу в эту секцию

Пробуем (и помним, что stageTest в FG1):

Ну неплохо, т.е. прочитали только левую секцию (которую делим) и всё. Окей. Чтобы переключить несекционированную непустую таблицу в секцию секционированной таблицы, на таблице-источнике обязательно нужны ограничения, чтобы SQL Server знал, что всё будет хорошо и переключение можно сделать как операцию над метаданными (а не читать всё подряд и проверять – подходит под условия секции или нет):

Опять-таки, операция только над метаданными. Смотрим, что там с нашими секциями:

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

Посмотрим, какие секции есть у нас сейчас:

Отлично, теперь у нас три «логичных» секции – с начала времен до 01.04.2018 00:00:00 (не включительно), с 01.04.2018 00:00:00 (включительно) по 01.08.2018 00:00:00 (не включительно) и третья, всё, что больше или равно 01.08.2018 00:00:00.

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

1. Добавляем новую секцию:

Неплохо, по крайней мере разумно – прочитали только крайнюю секцию. Смотрим, что там у нас по секциям:

Обратите внимание, что теперь, заполненная третья секция осталась на месте, в FG3, а новая пустая секция создалась в FG1.

2. Создаём stage-таблицу и ПРАВИЛЬНЫЙ кластерный индекс по ней

3. Переключаем секцию

Статистика говорит, что операция над метаданными:

Теперь уже всё без сюрпризов.

4. Убираем ненужную секцию

А вот тут нас ждёт сюрприз:

Смотрим, что там у нас с секциями:

И вот тут становится понятно: наша секция #2 переехала из файловой группы fg2 в файловую группу fg1. Класс. Можем ли мы с этим что-то сделать?

Можем, просто нам всегда надо иметь пустую секцию и «уничтожать» границу между «вечнопустой» левой секций и той секцией, которую мы «переключили» (switch) в другую таблицу.

В качестве заключения:

  1. Используйте полный синтаксис create partition function, не полагайтесь на значения по умолчанию – вы можете получить не то, что хотели.
  2. Держите слева и справа по пустой секции – они вам очень пригодятся при организации «скользящего окна».
  3. Split и merge непустых секций – это всегда больно, по возможности избегайте этого.
  4. Проверьте свои запросы — если они не используют фильтр по тому столбцу, по которому вы планируете секционировать таблицу и вам нужна возможность переключения секций — их производительность может значительно снизиться.
  5. Если вы хотите что-то сделать, сначала протестируйте не в продакшене.

Надеюсь, материал был полезен. Возможно вышло скомкано, если считаете, что что-то из заявленного не раскрыто, пишите, постараюсь доделать. Спасибо за внимание.

Ссылка на основную публикацию
Учимся рисовать в paint
Серия видео уроков «Создание компьютерного рисунка в программе Paint» МОУ «Межборская средняя общеобразовательная школа» (Уроки предназначены для детей 9-12 лет,...
Умный браслет с функцией измерения давления
Вы посвящаете свою жизнь спорту или просто стараетесь всеми возможными способами следить за своим здоровьем? Придерживаетесь того, что во время...
Умный выключатель zigbee aqara
Протокол передачи данных в домашних системах автоматизации. Реле Xiaomi Aqara Xiaomi Aqara wireless relay Систему "Умного дома" сложно представить без...
Учиться без троек сканворд
Музыкант, играющий на барабанах, тарелках Передовой работник производства (ударник) Часть затвора стрелкового оружия (ударник) "Барабанщик" коммунистического труда (устар.) (ударник) "Барабанщик"...
Adblock detector