Mysql расширение файла бд

Обновлено: 05.07.2024

Каждая таблица представлена в каталоге базы данных в виде трех файлов: файла формы (описания), файла данных и файла индексов. Основное имя файла соответствует названию таблицы, а его расширение отражает тип файла . Краткое описание расширений представлено в табл. 7.1. По расширениям файлов данных и индексов можно определить, используется ли в таблице старый формат ISAM или новый MyISAM .

При выполнении оператора CREATE TABLE tblname , определяющего структуру таблицы, сервер создает файл tblname.frm с внутренней кодировкой структуры. Кроме того, создаются также файлы данных и индексов с информацией об отсутствии записей и индексов. (Если оператор create table включает спецификации индексов, в файле индексов они отражаются соответствующим образом.) Параметры владельца и режима файлов таблицы устанавливаются такими, чтобы обеспечить доступ только пользователю сервера MySQL .

При исполнении оператора alter table расшифровывает файл tbl_name.frm и изменяет файлы данных и индексов с учетом определенных оператором структурных изменений. Такие же операции имеют место и при выполнении операторов create index и drop index , поскольку они рассматриваются сервером как эквивалентные оператору ALTER table . В процессе выполнения оператора drop table из каталога базы данных удаляются все три представляющих таблицу файла.

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

Вывод оператора SHOW tables mydb представляет собой простой список имен (без расширений) FRM -файлов каталога базы данных my_db . Как уже отмечалось ранее, некоторые СУБД поддерживают специальный реестр со списком всех таблиц баз данных. В MySQL такой реестр не нужен, поскольку список таблиц легко определяется благодаря структуре каталога данных.

Ограничения операционной системы на имена баз данных и таблиц

В MySQL устанавливается несколько основных правил присвоения имен базам данных и таблицам.

Имена могут включать буквы и цифры текущего набора символов, а также символы подчеркивания и доллара ("_" и "$").

Длина имен не может превышать 64 символа.

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

Во-первых, в именах баз данных и таблиц можно использовать только разрешенные для имен файлов символы. Так, например, символ "$" разрешается правилами MySQL , однако в некоторых операционных системах его нельзя применять в именах файлов. Такого рода ограничения отсутствует в ОС UNIX и Windows . Наиболее значительные проблемы могут возникнуть в момент ссылки на имена баз данных при выполнении задач администрирования непосредственно из оболочки. Предположим, например, что база данных имеет имя $my_db . В этом случае всякая ссылка на имя базы может интерпретироваться как ссылка на переменную:

Чтобы избежать возможных недоразумений, нужно либо вообще избегать использования символа "$", либо использовать кавычки, подтверждая его специальное значение :

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

Во-вторых, несмотря на то, что MySQL разрешает задавать для баз данных и таблиц имена длиной до 64 символов, на самом деле их длина ограничивается максимально возможной длиной имен файлов. В большинстве случаев эта проблема как таковая отсутствует, хотя в некоторых UNIX -системах System V все еще существует старое ограничение в 14 символов. В таком случае имя таблицы должно содержать не более 10 символов, поскольку четыре остальных позиции отводится под точку и трехсимвольное расширение.

В-третьих, на присвоение имен базам данных и таблицам оказывает влияние также чувствительность используемой файловой системы к регистру символов. Если буквы нижнего и верхнего регистров операционной системой воспринимаются по -разному (как, например, в ОС UNIX ), имена my_tbl и My_tbl будут указывать на разные таблицы. Если же регистр не играет никакой роли (как, например, в Windows ), my_tbl и My_tbl окажутся разными названиями одной и той же таблицы. Об этом следует помнить при разработке базы данных , которую впоследствии планируется перенести на другую платформу.

Каждая база данных SQL Server имеет как минимум два рабочих системных файла: файл данных и файл журнала. Файлы данных содержат данные и объекты, такие как таблицы, индексы, хранимые процедуры и представления. Файлы журнала содержат сведения, необходимые для восстановления всех транзакций в базе данных. Файлы данных могут быть объединены в файловые группы для удобства распределения и администрирования.

Файлы базы данных

SQL Server имеют три типа файлов.

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

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

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

Логические и физические имена файлов

Файлы SQL Server имеют два типа имен файлов.

logical_file_name: имя, используемое для ссылки на физический файл во всех инструкциях Transact-SQL. Логическое имя файла должно соответствовать правилам для идентификаторов SQL Server и быть уникальным среди логических имен файлов в соответствующей базе данных.

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

Дополнительные сведения об аргументах NAME и FILENAME см. в статье Параметры ALTER DATABASE ((Transact-SQL)) для файлов и файловых групп.

Файлы данных и файлы журналов SQL Server могут использоваться как в файловой системе FAT, так и в системе NTFS. В системах Windows рекомендуется использовать файловую систему NTFS по причинам ее большей безопасности.

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

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

Размер файла

Файлы SQL Server могут автоматически увеличиваться в размерах, превосходя первоначально заданные показатели. При определении файла пользователь может указывать требуемый шаг роста. Каждый раз при заполнении файла его размер увеличивается на указанный шаг роста. Если в файловой группе имеется несколько файлов, их автоматический рост начинается лишь по заполнении всех файлов.

Дополнительные сведения о страницах и их типах см. в разделе Руководство по архитектуре страниц и экстентов.

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

Дополнительные сведения об управлении файлами журнала транзакций см. в разделе Управление размером файла журнала транзакций.

Файлы моментального снимка базы данных

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

• Данные моментального снимка базы данных, созданного пользователем, хранятся в одном или нескольких разреженных файлах. Технология разреженных файлов является свойством файловой системы NTFS. Изначально разреженный файл не содержит данных пользователя, и место на диске под него не выделяется. Общие сведения об использовании разреженных файлов в моментальных снимках базы данных и о том, как растут моментальные снимки базы данных, см. в разделе Просмотр размера разреженного файла моментального снимка базы данных.
• Моментальные снимки базы данных могут использоваться внутренними механизмами при выполнении определенных команд DBCC. Эти команды включают DBCC CHECKDB, DBCC CHECKTABLE, DBCC CHECKALLOC и DBCC CHECKFILEGROUP. Внутренним моментальным снимком базы данных используются разреженные дополнительные потоки данных исходных файлов базы данных. Подобно разреженным файлам, дополнительные потоки данных являются свойством файловой системы NTFS. Использование разреженных дополнительных потоков данных позволяет связать несколько расположений данных с одним файлом или папкой, не затрагивая при этом размер файла или статистику тома.

Файловые группы

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

Например, Data1.ndf , Data2.ndf и Data3.ndf могут быть созданы на трех дисках соответственно и отнесены к файловой группе fgroup1 . В этом случае можно создать таблицу на основе файловой группы fgroup1 . Запросы данных из таблицы будут распределены по трем дискам, и это улучшит производительность. Подобного улучшения производительности можно достичь и с помощью одного файла, созданного на чередующемся наборе дискового массива RAID. Тем не менее файлы и файловые группы позволяют без труда добавлять новые файлы на новые диски.

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

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

Файловая группа по умолчанию (первичная)

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

Файловая группа PRIMARY является группой по умолчанию, если только она не была изменена инструкцией ALTER DATABASE. Системные объекты и таблицы распределяются внутри первичной файловой группы, а не новой файловой группой по умолчанию.

Файловая группа данных, оптимизированных для памяти

Дополнительные сведения об оптимизированных для памяти файловых группах см. в разделе Оптимизированные для памяти файловые группы.

Файловая группа файлового потока

Дополнительные сведения о файловых группах файлового потока см. в статьях FILESTREAM и Создание базы данных с поддержкой FILESTREAM.

Пример файлов и файловых групп

В следующем примере создается база данных на основе экземпляра SQL Server. База данных содержит первичный файл данных, пользовательскую файловую группу и файл журнала. Первичный файл данных входит в состав первичной файловой группы, а пользовательская файловая группа состоит из двух вторичных файлов данных. Инструкция ALTER DATABASE придает пользовательской файловой группе статус файловой группы по умолчанию. Затем создается таблица, определяющая пользовательскую файловую группу. (В этом примере используется универсальный путь к c:\Program Files\Microsoft SQL Server\MSSQL.1 , чтобы не указывать версию SQL Server.)

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

Стратегия заполнения файлов и файловых групп

В файловых группах для каждого файла используется стратегия пропорционального заполнения. При записи данных в файловую группу компонент Компонент SQL Server Database Engine записывает в каждый файл количество данных, пропорциональное свободному пространству этого файла, вместо записи всех данных в первый файл до его заполнения. Затем запись производится в следующий файл. Например, если в файле f1 свободно 100 МБ, а в файле f2 — 200 МБ, то в файл f1 записывается одна часть данных, а в файл f2 — две части, и так далее. Таким образом, оба файла будут заполнены примерно в одно и то же время, и достигается простейшее распределение данных между хранилищами.

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

Правила проектирования файлов и файловых групп

Для файлов и файловых групп действуют следующие правила:

• файл или файловая группа не могут использоваться несколькими базами данных. Например, файлы sales.mdf и sales.ndf, содержащие данные и объекты базы данных sales, не могут использоваться никакой другой базой данных.
• файл может быть элементом только одной файловой группы;
• файлы журнала транзакций не могут входить ни в какие файловые группы.

Рекомендации

Рекомендации при работе с файлами и файловыми группами:

• Для большинства баз данных достаточно использовать один файл данных и один файл журнала транзакций.
• При использовании множества файлов данных создайте вторую файловую группу с дополнительным файлом и сделайте ее файловой группой по умолчанию. Тогда в первичном файле будут храниться только системные таблицы и объекты.
• Чтобы увеличить производительность, по возможности разнесите файлы и файловые группы по нескольким доступным дискам. Объекты, активно конкурирующие за свободное пространство, поместите в разные файловые группы.
• Используйте файловые группы для целенаправленного размещения объектов на конкретных физических дисках.
• Помещайте разные таблицы, использующиеся в одних и тех же запросах с соединениями, в разные файловые группы. Этот этап увеличит производительность, так как для поиска соединяемых данных можно будет использовать параллельный ввод-вывод.
• Часто используемые таблицы и некластеризованные индексы, относящиеся к ним, помещайте в разные файловые группы. Использование разных групп файлов увеличит производительность, так как можно будет использовать параллельный ввод и вывод, если файлы находятся на разных жестких дисках.
• Не помещайте файлы журнала транзакций на тот же физический диск, где находятся другие файлы и файловые группы.
• Если необходимо расширить том или раздел, в котором находятся файлы базы данных, с помощью таких средств, как Diskpart, следует сначала выполнить резервное копирование всех системных и пользовательских баз данных и остановить службы SQL Server. Кроме того, после успешного расширения томов дисков рекомендуется выполнить команду DBCC CHECKDB , чтобы обеспечить физическую целостность всех баз данных в томе.

Дополнительные рекомендации по управлению файлами журнала транзакций см. в разделе Управление размером файла журнала транзакций.

Область применения: База данных Azure для MySQL — отдельный сервер

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

Подробные и исчерпывающие инструкции по миграции см. в разделе Ресурсы руководств по миграции.

Другие сценарии миграции рассматриваются в руководстве по переносу баз данных.

Предварительные требования

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

• Создайте базу данных Azure для сервера MySQL с помощью портала Azure.
• Скачайте и установите MySQL Workbench или другое стороннее средство MySQL для импорта и экспорта.

Создание базы данных в службе базы данных Azure для сервера MySQL

Создайте пустую базу данных на сервере базы данных Azure для MySQL с помощью инструментов MySQL Workbench, Toad или Navicat. База данных может иметь то же имя, что и база данных, которая содержит данные дампа. Вы также можете создать базу данных с другим именем.

Для подключения выполните следующие действия.

На портале Azure найдите сведения о подключении на панели Обзор базы данных Azure для MySQL.

Добавьте сведения о подключении MySQL Workbench.

Определите необходимость использования методов импорта и экспорта

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

В следующих сценариях следует использовать средства MySQL для импорта и экспорта баз данных в базу данных MySQL в Azure. Для сведений о работе с другими инструментариями перейдите к разделу "Методы миграции" (стр. 22) в руководстве по миграции базы данных MySQL в Azure.

• Если вам нужно выбрать несколько таблиц для импорта из имеющейся базы данных MySQL в базу данных Azure, лучше всего использовать метод импорта и экспорта. Таким образом, можно пропустить все ненужные таблицы в процессе переноса, чтобы сэкономить время и ресурсы. Например, используйте параметр --include-tables или --exclude-tables с mysqlpump и параметр --tables с mysqldump.
• При перемещении объектов, отличных от таблиц, необходимо будет явно создать эти объекты. Включите ограничения (первичный ключ, внешний ключ, индексы), представления, функции, процедуры, триггеры и другие объекты базы данных, которые требуется перенести.
• При перемещении данных из внешних источников данных, отличных от базы данных MySQL, создайте неструктурированные файлы и импортируйте их с помощью команды mysqlimport.

Как Отдельный сервер, так и Гибкий сервер поддерживают только подсистему хранилища InnoDB. Убедитесь, что все таблицы в базе данных используют подсистему хранилища InnoDB при загрузке данных в базу данных Azure для MySQL.

Если база данных источника использует другую подсистему хранилища, преобразуйте ее в подсистему InnoDB перед переносом базы данных. Например, при наличии WordPress или веб-приложения, которое использует ядро MyISAM, сначала преобразуйте таблицы путем переноса данных в таблицы InnoDB. Используйте предложение ENGINE=INNODB , чтобы задать ядро для создания таблицы, а затем передайте данные в совместимую таблицу перед переносом.

Рекомендации по повышению производительности импорта и экспорта

Для оптимальной производительности импорта и экспорта данных рекомендуется выполнить следующие действия:

• Создайте кластеризованные индексы и первичные ключи перед загрузкой данных. Загрузите данные в порядке первичных ключей.
• Отложите создание вторичных индексов до завершения загрузки данных.
• Отключите ограничения внешних ключей перед загрузкой данных. Отключение проверки внешнего ключа обеспечивает значительный прирост производительности. Включите ограничения и проверьте данные после загрузки, чтобы обеспечить целостность данных.
• Загружайте данные в параллельном режиме. Не выполняйте слишком много параллельных операций, так как ресурсы при этом могут кончиться. Отслеживайте ресурсы с помощью метрик, доступных на портале Azure.
• Используйте секционированные таблицы, когда это необходимо.

Импорт и экспорт с помощью MySQL Workbench

Существует два способа экспорта и импорта данных в MySQL Workbench: из контекстного меню обозревателя объектов или из области навигатора. Каждый из них предназначен для своей цели.

Если вы добавляете подключение к MySQL Single Server или гибкому серверу в MySQL Workbench, выполните следующие действия.

• Если используется Отдельный сервер MySQL, убедитесь, что имя пользователя имеет формат <username@servername> .
• Для Гибкого сервера MySQL следует использовать только <username> . При использовании <username@servername> для подключения произойдет сбой.

Запустите мастера экспорта и импорта данных таблиц в контекстном меню обозревателя объектов

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

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

Мастер экспорта данных таблиц

Для выполнения экспорта таблицы в CSV-файл:

1. Щелкните правой кнопкой мыши таблицу базы данных, которую необходимо экспортировать.
2. Выберите Table Data Export Wizard (Мастер экспорта данных таблиц). Выберите столбцы, которые необходимо экспортировать, смещение строки (при необходимости) и количество (при необходимости).
3. На панели Выбор данных для экспорта нажмите кнопку Далее. Выберите путь к файлу, тип файла CSV или JSON. Также выберите разделитель строк, метод включения строк и разделитель полей.
4. На странице Выбор расположения выходного файла щелкните Далее.
5. На панели Экспорт данных нажмите кнопку Далее.

Мастер импорта данных таблиц

Чтобы импортировать таблицу из файла CSV, выполните следующее:

1. Щелкните правой кнопкой мыши таблицу базы данных, которую необходимо импортировать.
2. Найдите CSV-файл, который необходимо импортировать, выберите его, а затем щелкните Далее.
3. Выберите таблицу назначения (новую или имеющуюся), установите или снимите флажок Усечение таблицы перед импортом, затем нажмите Далее.
4. Выберите кодировку и столбцы, которые необходимо импортировать, и нажмите кнопку Далее.
5. На панели Импорт данных нажмите кнопку Далее. Мастер импортирует данные.

Запуск мастеров экспорта и импорта данных SQL через панель Навигатора

Используйте мастер для экспорта или импорта данных SQL, созданных в MySQL Workbench или с помощью команды mysqldump. Вы можете получить доступ к мастерам из области Навигатора или выбрать пункт Сервер в главном меню.

Экспорт данных

Используйте вкладку Экспорт данных для экспорта данных MySQL.

В MySQL Workbench в области Навигатор выберите Экспорт данных.

На панели Экспорт данных выберите каждую из схем, которые необходимо экспортировать.

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

В качестве альтернативы можно использовать команду Export a Result Set (Экспортировать результирующий набор), чтобы выполнить экспорт конкретного результирующего набора из редактора SQL в другой формат, например CSV, JSON, HTML или XML.

Выберите объекты базы данных, которые необходимо экспортировать, и настройте связанные параметры.

Щелкните Обновить, чтобы загрузить текущие объекты.

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

Щелкните Начать экспорт, чтобы начать процесс экспорта.

Импорт данных

Вкладку Импорт данных можно использовать для импорта или восстановления данных из операции экспортирования данных или из команды mysqldump.

Из этого руководства вы узнаете, как перенести базы данных MySQL в SQL Server.

Предварительные требования

Прежде чем приступить к переносу базы данных MySQL в SQL Server, сделайте следующее:

• Убедитесь, что ваша исходная среда поддерживается. В настоящее время поддерживаются MySQL 5.6 и 5.7.
• Получите Помощник по миграции SQL Server для MySQL (SSMA для MySQL).
• Получите возможность подключения и требуемые разрешения для доступа к исходному и целевому объектам.

Подготовка к миграции

После выполнения необходимых условий можно приступать к анализу исходной среды MySQL и оценке возможности миграции.

Оценка

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

Чтобы создать оценку, выполните следующие действия.

Откройте SSMA для MySQL.

В меню Файл выберите пункт Создать проект.

Укажите имя проекта, расположение для сохранения проекта и целевой объект миграции. Для параметра Перенести в выберите значение SQL Server.

Укажите сведения о подключении в диалоговом окне Подключение к MySQL и подключитесь к серверу MySQL.

Выберите базы данных MySQL, которые требуется перенести.

Щелкните правой кнопкой мыши базу данных MySQL в области Обозреватель метаданных MySQL и выберите команду Создать отчет. Можно также выбрать вкладку Создание отчета в правом верхнем углу.

Ознакомьтесь с HTML-отчетом, чтобы получить сведения о статистике преобразований и любых ошибках или предупреждениях. Также можно открыть отчет в Excel, чтобы получить список объектов MySQL и действий, необходимых для выполнения преобразований схемы. По умолчанию отчет находится в папке report в каталоге SSMAProjects, как показано ниже.

Проверка сопоставлений типов

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

В меню Сервис выберите Параметры проекта.

Перейдите на вкладку Type mapping (Сопоставление типов).

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

Дополнительные сведения о параметрах преобразования в SSMA для MySQL см. в статье Параметры проекта (преобразование) (MySQLToSQL).

Преобразование схемы

Преобразование объектов баз данных происходит следующим образом: определения объектов берутся из MySQL, преобразуются в аналогичные объекты SQL Server, а затем эти сведения загружаются в метаданные SSMA для MySQL. Сведения не загружаются в экземпляр SQL Server. Затем можно просмотреть объекты и их свойства в Обозревателе метаданных SQL Server.

Чтобы преобразовать схему, выполните следующие действия.

(Необязательно) Чтобы преобразовать динамические или специальные запросы, щелкните узел правой кнопкой мыши и выберите команду Добавить инструкцию.

Откройте вкладку Подключение к SQL Server.

1. Введите сведения о подключении для экземпляра SQL Server.
2. Выберите целевую базу данных в раскрывающемся списке или укажите новое имя. В этом случае база данных будет создана на целевом сервере.
3. Введите сведения о проверке подлинности и нажмите кнопку Подключить.

Щелкните правой кнопкой мыши базу данных MySQL в области Обозреватель метаданных MySQL и выберите пункт Преобразовать схему. Кроме того, можно выбрать вкладку Преобразование схемы в правом верхнем углу.

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

Сравните преобразованный текст Transact-SQL с исходным кодом и просмотрите рекомендации.

В области вывода выберите элемент Просмотр результатов и проверьте ошибки в области Список ошибок.

Миграция

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

Доступны два варианта переноса.

Перенос данных на стороне клиента

• Для переноса данных на стороне клиента в диалоговом окне Параметры проекта выберите вариант Подсистема переноса данных на стороне клиента.

Если целевой базой данных является выпуск SQL Express Edition, то разрешен только перенос данных на стороне клиента. Перенос данных на стороне сервера не поддерживается.

Перенос данных на стороне сервера

• Прежде чем выполнять перенос данных на стороне сервера, необходимо выполнить следующие требования:
  • пакет расширений SSMA для MySQL должен быть установлен в экземпляре SQL Server;
  • служба агента SQL Server должна быть запущена в экземпляре SQL Server.

  Если вы планируете использовать подсистему переноса данных на стороне сервера, то перед переносом необходимо установить пакет расширения SSMA для MySQL и поставщики MySQL на компьютере, на котором выполняется SSMA для MySQL. Кроме того, должна быть запущена служба агента SQL Server. Дополнительные сведения об установке пакета расширения см. в разделе Установка компонентов SSMA в SQL Server (миграция из MySQL в SQL).

  Чтобы опубликовать схему и перенести данные, выполните следующие действия.

  Опубликуйте схему. Для этого щелкните правой кнопкой мыши базу данных в области Обозреватель метаданных SQL Server и выберите пункт Синхронизировать с базой данных. В результате база данных MySQL будет опубликована в экземпляре SQL Server.

  
  

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

  
  

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

  
  

  После завершения миграции изучите отчет о переносе данных.

  
  

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

  
  

  После миграции

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

  Исправление приложений

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

  Выполнение тестов

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

  1. Разработка проверочных тестов. Чтобы протестировать перенос базы данных, необходимо использовать SQL-запросы. Необходимо создать запросы проверки, которые будут выполняться как в исходной, так и в целевой базах данных. Проверочные запросы должны охватывать всю определенную ранее область.
  2. Настройка тестовой среды. Тестовая среда должна содержать копию исходной и целевой баз данных. Не забудьте изолировать тестовую среду.
  3. Выполнение проверочных тестов. Выполните проверочные тесты в исходной и целевой базах данных, а затем проанализируйте результаты.
  4. Выполнение тестов производительности. Запустите тесты производительности для исходной и целевой баз данных, а затем проанализируйте и сравните результаты.

  Оптимизация

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

  Дополнительную информацию об этих проблемах и мерах по их устранению см. в руководстве по проверке и оптимизации после миграции.

  Ресурсы, посвященные миграции

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

  Заголовок	Описание
  Модель и средство оценки рабочей нагрузки данных	Это средство предоставляет предлагаемые "оптимальные" целевые платформы, готовность к переходу в облако и уровень исправления приложения или базы данных для конкретной рабочей нагрузки. Оно обеспечивает простое и быстрое вычисление и создание отчетов, которое помогает ускорить оценку больших объемов, предоставляя, автоматизируя и унифицируя процесс принятия решения относительно целевой платформы.
  Из MySQL в SQL Server — средство сравнения баз данных	Средство сравнения баз данных — это консольное приложение Windows, которое позволяет проверить идентичность данных на исходной и целевой платформах. Это средство можно использовать для эффективного сравнения данных на уровне строк или столбцов во всех или выбранных таблицах, строках и столбцах.

  Эти ресурсы разработали специалисты по разработке данных SQL. Основная задача этой команды — включить и ускорить комплексную модернизацию проектов миграции платформы данных на платформу данных Microsoft Azure.

  Читайте также:

    
  • Чем слушать dsd на компьютере
    
  • Как передать сокет в другой процесс
    
  • Как отметить пароль для входа в ноутбук
    
  • Игры на компьютер по типу винкс
    
  • Как сделать зеленый кружок в хамачи