• Статья

Практическое руководство по SQL Server 2008 для профессионалов Oracle

Вступление

В компаниях Oracle и Microsoft используются определенные понятия экземпляров и баз данных. Во многом они схожи, но имеют и специфические различия. Поскольку продукты Oracle и Microsoft представлены на рынке уже много лет и продолжают совершенствоваться, некоторые термины («сервер», «системы», «экземпляр» и «база данных») использовались для описания одного объекта в сравнении с другим. Даже производители внесли свой вклад в создание терминологических противоречий. База данных Oracle - это не просто набор файлов базы данных для отдельного экземпляра. Аналогично, продукт Microsoft® SQL Server® не налагает ограничения в виде работы только одного экземпляра на отдельном физическом сервере.

Концепция экземпляров и баз данных Oracle

База данных Oracle реализована в виде набора двоичных файлов. Сюда входят исполняемые файлы программного обеспечения, сетевых файлов и инструментов администрирования. Устанавливаются также «файлы баз данных», которые содержат файлы управления, файлы табличного пространства и файлы журнала.

При запуске экземпляра Oracle на сервере Windows® осуществляется доступ к файлам инициализации (SPFILE или init.ora), чтобы определить параметры, необходимые для начала работы сервиса. Далее Oracle резервирует определенный объем оперативной памяти, доступный в рамках операционной системы, в специальном буфере, именуемом системной глобальной областью (SGA). После этого Oracle осуществляет контроль фоновых процессов. Эти фоновые процессы задействуют потоки Windows для выполнения кодов системными процессорами и обеспечивают изоляцию от других приложений, работающих в системе. После запуска экземпляра приложения можно смонтировать базу данных путем считывания информации из управляющего файла БД. В завершение база данных открывается для запросов клиентов. Открытие и даже монтирование базы данных не является обязательным. Экземпляр остается в запущенном состоянии и отслеживает сетевые запросы.

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

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

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

Реализация экземпляров и баз данных SQL Server

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

На одном компьютере можно запустить несколько экземпляров SQL Server. Основной целью архитектуры с поддержкой нескольких экземпляров является разграничение ресурсов для различных операций баз данных в рамках одной физической системы. Каждый экземпляр независимо использует системные ресурсы памяти и процессора. SQL Server 2008 поддерживает до 50 экземпляров в версиях Standard Еdition и Enterprise Еdition.

Все это уже знакомо? Так и должно быть. Oracle и SQL Server представляют собой системы управления реляционными базами данных (RDBMS) - разновидность решений DBMS. Несмотря на схожие характеристики обоих продуктов, упомянутые выше, присутствуют и различия. В отличие от Oracle, где одни и те же двоичные файлы используются для нескольких экземпляров, SQL Server требует отдельного набора двоичных файлов, которые устанавливаются для каждого экземпляра. В Microsoft было принято решение не только защитить процессы и память отдельных экземпляров, но также и физический файл - чтобы обеспечить изоляцию от проблем носителей в той части, где записаны двоичные файлы. Предусмотрена дополнительная защита для экземпляров, которым может потребоваться модернизация или если в их состав необходимо включить конкретный файл. Эти задачи решаются без задействования двоичных файлов экземпляров и, следовательно, приложений, не протестированных с обновленной версией, или для которых не требуются изменения.

Экземпляр может быть связан не с одной базой данных. Фактически, каждый установленный экземпляр имеет собственный набор из четырех «системных» баз данных, в которых хранится конфигурация его параметров. Эти базы данных обеспечивают функции, схожие с функциями управляющих файлов в Oracle. Их можно рассматривать как контейнер для одной или более баз данных. Все это тоже знакомо? Представление о том, что базы данных эквивалентны схемам, верно лишь отчасти.

Администраторы баз данных SQL Server могут установить экземпляр на компьютер. Далее они могут создать БД, отделенную от системных баз данных, которые упоминались выше. В этой базе будут присутствовать объекты, в том числе таблицы. Эти объекты обеспечивают работу какой-то определенной функциональности. Разграничение процессов дает преимущества в управлении и обеспечивает безопасность. Подобное разграничение применяется не только к файлам данных, но также к операциям по каждой базе данных. В Oracle используются журналы повторов действий в отношении экземпляра и одной соответствующей ему БД. Как и в Oracle, каждая база данных должна использовать некий файл - файл журнала - для отслеживания операций и управления ими. В связи с этим каждая база данных имеет свою собственную уникальную систему учета операций.

Архитектура хранения

При работе с блоками, экстентами и сегментами возникают два вопроса. Что дает наличие фиксированных блоков размером 8 КБ и фиксированных экстентов размером 64 КБ в отношении внутренней фрагментации вследствие изменяющегося размера экстента? Эти вопросы являются главной заботой администраторов баз данных.

Рисунок 1. Организация ядра базы данных Oracle в сравнении с SQL Server

В Oracle размер экстентов варьируется, поэтому данные иногда записываются в разные участки (не занимают непрерывную область). В SQL Server экстенты имеют одинаковый размер (64 КБ), поэтому данные могут записываться и загружаться с одного места их хранения на диске, в отличие от Oracle, где они хранятся в разных местах диска. Фрагментация в рамках табличного пространства (файловая группа в SQL Server), которая горячо обсуждается в кругах, близких к Oracle, не актуальна для SQL Server благодаря использованию экстентов фиксированного размера.

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

Как в Oracle, так и в SQL Server пространство, необходимое для определения и использования объектов схемы (триггеры, процедуры и тому подобное) и объектов системного уровня (пользователи, роли и тому подобное), выделяется из словаря данных.

Сопоставление баз данных

Каждый экземпляр в SQL Server имеет две структуры баз данных - model и msdb, эквивалентов которым в Oracle нет. База данных model формирует шаблон, используемый для создания новых баз данных. Это напоминает отчасти создание первоначальной схемы при помощи служебной программы Oracle, используемой для изменения конфигурации баз данных. База данных msdb используется приложением SQL Server Agent для хранения информации о заданиях, событиях, расписаниях, операторах и так далее. В этой базе данных совмещены функции, обеспечиваемые в Oracle пакетом RDBMS_JOBS (DBMS_JOB и DBMS_SCHEDULER) и хранилищем Intelligent Agent.

В таблице ниже представлены табличные пространства Oracle и эквивалентные структуры представления памяти в SQL Server (где это возможно).

Таблица 1. Табличные структуры памяти в Oracle и SQL Server, выполняющие эквивалентные функции SQL Server Oracle

SQL Server Oracle
Главная (master) база данных Системное табличное пространство
Главная (master) база данных Табличное пространство Sysaux
База данных ресурсов Табличное пространство System/Sysaux
База данных tempdb Временное табличное пространство
Журнал операций Табличное пространство возврата (откат)
Журнал операций Интерактивный журнал откатов
База данных «Приложение» - файловая группа «Данные» Табличное пространство Application Bigfile Data
База данных «Приложение» - файловая группа «Данные» Табличное пространство Application Data
База данных «Приложение» - файловая группа «Данные» Табличное пространство Application Index
База данных model Нет аналога в Oracle
База данных msdb Нет аналога в Oracle

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

  • В SQL Server каждая база данных имеет собственные файлы журнала операций, которые совмещают функции интерактивных журналов откатов в Oracle и сегменты отмены/откатов.
  • Каждая база данных SQL Server располагает собственными структурами безопасности: пользователи, привилегии (разрешения) и роли.
  • Каждая база данных SQL Server располагает собственными ролями, обеспечивающими привилегии конкретной базе данных.
  • В SQL Server имеется системный каталог, аналогичный словарю данных в Oracle. Он разбивается на отдельные базы данных - базу данных master и ресурсную БД (он имеет атрибуты «скрытый» и «только для чтения»).
  • Временное пространство (tempdb в SQL Server и временное табличное пространство в Oracle) является общим для всего экземпляра.

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

Модель ведения журнала

Интерактивные журналы отмены действий используются в Oracle для регистрации изменений (DML и DDL), внесенных в базу данных до того, как эти изменения будут применены к файлам БД. В SQL Server журналы отмены действий называются журналами транзакций. В Oracle тоже используются табличные пространства для повторяемых операций, выполняемых с созданием образа данных до начала их изменения (предшествующие образы). Это облегчает отмену операции, восстановление и последовательное считывание (многоверсионный конкурентный доступ).

Для хранения информации о повторяющихся операциях в предыдущих версиях БД Oracle использовались сегменты отката. В Oracle9i представлена функция автоматического управления откатами, что упростило управление дисковым пространством для отмены действий за счет устранения сложностей, связанных с управлением сегментами отката.

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

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

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

Рисунок 2. Архитектура журнала транзакций SQL Server

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

Рисунок 3. Циклические переходы в журнале транзакций SQL Server

Так же как и сегменты отката в Oracle, виртуальные записи журнала могут быть перезаписаны при применении соответствующих транзакций. Функции и вопросы администрирования журналов транзакций в SQL Server представляют собой сочетание таковых для сегментов и журналов откатов в Oracle. При возврате к началу журнала дисковое пространство используется повторно только в том случае, если транзакции завершены (согласно сегментам откатов), контрольные точки успешно пройдены (как в журналах откатов), а данные - удалены из виртуальных файлов журнала посредством архивирования журнала (Backup Log). При архивировании журнала производится усечение данных, относящихся к завершенным транзакциям. При выполнении операции усечения происходит удаление записей виртуальных журналов до определенного LSN первой записи образа журнала или минимального номера в журнале восстановления (MinLSN). Разработка оптимального графика резервирования (как и графика архивирования журнала) обеспечивает эффективные циклы без каких-либо проблем.

В SQL Server наиболее эффективным является задание оптимального размера журнала транзакций. Необходимо подключить в SQL Server функцию автоматического расширения (autogrow). Это нужно для того, чтобы увеличивающиеся файлы журналов поддерживались даже при нехватке дискового пространства в БД (это может наступить в результате неожиданного увеличения числа транзакций в период между процедурами резервирования, если администраторы не задали должный размер журнала). Функция автоматического расширения подключается только в случае полного истощения дисковых ресурсов журнала, поэтому имеет смысл отслеживать в журнале свободное место и вручную увеличивать его размер до того, как включится данная функция. Функция автоматического сжатия обычно не используется. Ее выполнение приводит к уменьшению размера файлов журнала только для того, чтобы затем их размер был увеличен функцией автоматического расширения. Эти функции действуют схожим образом на функции сегментов откатов, авторасширения и сжатия.

Архивация и восстановление

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

Менеджер восстановления используется для архивации и восстановления баз данных.

Другой метод подразумевает архивацию и восстановление, производимые пользователем. Архивация выполняется средствами операционной системы, а для восстановления используется SQL*Plus. Архивация в Oracle производится с учетом определенных и неопределенных состояний. Их можно рассматривать как «холодную» и «горячую» архивацию.

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

Логическая архивация

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

В SQL Server отдельные объекты схемы можно архивировать в виде неструктурированных файлов любого поддерживаемого формата. Далее неструктурированные файлы можно восстановить с помощью таких инструментов, как утилита bcp (инструмент, запускаемый из командной строки и использующий программу массового копирования, BCP, API), команда BULK INSERT, мастера импорта и экспорта, а также службы SQL Server Integration Services.

Физическая архивация

Физическая архивация - это непосредственное копирование файлов базы данных. В Oracle в файлы БД входят файлы данных, управляющие файлы и заархивированные файлы журнала откатов (если для базы данных включен режим ARCHIVELOG MODE).

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

Последовательная/холодная архивация

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

Для создания последовательной и полной архивной версии базы данных в Oracle необходимо прекратить работу базы данных при помощи опций NORMAL, IMMEDIATE или TRANSACTIONAL. Далее производится архивация при закрытой базе данных.

В SQL Server базы данных можно архивировать без их отключения. Функция полной архивации БД без отключения позволяет произвести операции, аналогичные таковым при последовательной или холодной архивации в Oracle. С помощью этого метода можно выполнить архивацию всей базы данных или части журнала транзакций. Но для этого не требуется отключение базы данных - в процессе архивации допускается наличие активных соединений. После восстановления из подобной архивной копии база данных восстанавливается до некоего последовательного состояния. Ее можно открыть с возможностью доступа, если отсутствует необходимость в дальнейшем использовании архивных версий журнала транзакций.

В SQL Server полная архивация сохраняет версию базы данных на момент окончания архивации. Полная архивация без отключения базы данных в SQL Server является во всех отношениях достаточной для последовательного восстановления БД. Полученная в результате архивации БД отражает состояние архивируемой базы данных на момент завершения архивации.

Выборочная/оперативная архивация

С учетом современных требований к доступности систем в режиме 24 х 7 полный вывод базы данных из эксплуатации представляется затруднительным. В таких ситуациях Oracle позволяет осуществить оперативное резервное копирование. При оперативной архивации производится выборочное копирование, когда фиксируются не все изменения SCN. Режим ARCHIVELOG базы данных дает возможность определять различные табличные пространства и создавать расписания архивирования управляющих файлов. В результате процесс распределяется по времени, обеспечивая то преимущество, что затрагиваются только заданные табличные пространства (а не все), благодаря чему отдельные процессы архивации занимают меньше времени. Это важно, если время сниженной нагрузки на систему (позволяющее произвести архивацию) не превышает время, требуемое для полной архивации. Использование RMAN при оперативном резервном копировании в Oracle позволяет не переводить табличные пространства в режим архивации.

В случае с SQL Server оперативная архивация базы данных позволяет получить полную версию БД с частью журнала транзакций. Полное, разностное или частичное резервное копирование файлов и файловых групп осуществляется с помощью инструкции BACKUP DATABASE или решения SQL Server Management Studio. Журналы транзакций можно резервировать по отдельности. Полное резервное копирование базы данных не приводит к удалению записей из журнала транзакций. Процесс архивации следует запускать периодически, чтобы очищать журнал и избежать его переполнения. Как правило, оптимальная методика архивации подразумевает периодическое архивирование журнала транзакций, что снижает актуальность этого вопроса. В резервную копию будут включены все транзакции, имевшие место на момент архивации.

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

Добавочная архивация

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

В Oracle добавочная архивация производится с помощью RMAN или программ сторонних разработчиков. При использовании RMAN производится сканирование файлов данных. Архивации подвергаются лишь измененные блоки. С помощью RMAN можно производить два типа добавочной архивации - собственно добавочную или разностную. Добавочные архивации (уровень 1) задействуют лишь те данные, которые были изменены со времени последней полной (уровень 0) или добавочной (уровень 1) архивации. Разностная архивация (тот же уровень 1) задействует все данные, измененные с момента последней полной архивации (уровень 0).

В SQL Server приведенные ниже методы архивации являются в чем-то аналогами добавочной архивации в Oracle.

  • Резервное копирование журнала транзакций - архивация журнала транзакций SQL Server выполняется с той же целью, что и добавочная архивация в Oracle. Этот тип архивации позволяет сохранить все транзакции, имевшие место с момента последней архивации журнала транзакций.
  • Разностная архивация - SQL Server обеспечивает архивацию всех данных, измененных с момента последней полной архивации. Этот тип архивации обеспечивает резервное копирование данных лишь с момента последней полной архивации. Разностная архивация не позволяет восстановить состояние системы на определенный момент времени или в привязке к определенной записи журнала.
  • Частичная архивация -- SQL Server поддерживает также частичную архивацию, когда копируются лишь данные из основной (Primary) файловой группы и файлы, предназначенные для чтения/записи. Частичная архивация не затрагивает файловые группы с атрибутом «только для чтения». Указание в инструкции BACKUP параметра READ_WRITE_FILEGROUPS позволяет произвести резервное копирование лишь файловых групп с атрибутом «чтение/запись» и не затрагивает группы «только для чтения»; предполагается, что эти файлы уже были заархивированы.

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

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

Безопасность баз данных

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

Oracle поддерживает несколько важных решений в сфере корпоративной безопасности, предназначенных для обеспечения целостности данных, конфиденциальности, однократной идентификации (SSO) и авторизации доступа. Применяется как вездесущий протокол безопасных соединений (SSL), так и «родная» схема шифрования данных Oracle Net. Строгая аутентификация - это обязательное условие, и реализуется она при помощи стандартов Kerberos, смарт-карт и цифровых сертификатов.

В SQL Server механизмы строгой аутентификации и шифрования данных встроены в систему. SQL Server обеспечивает шифрование данных, защиту доступа к базам паролем, использование сертификатов для выполнения сохраненных процедур, SSO и, разумеется, Kerberos и SSL для шифрования протоколов.

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

Рисунок 4. Шифрование данных в SQL Server

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

Прозрачное шифрование данных

В Oracle и SQL Server используется шифрование для защиты данных. В SQL Server 2008 представлено прозрачное шифрование данных (TDE). В Oracle имеется свой вид TDE, реализованный в виде основного ключа и бумажника. В Oracle использование TDE реализуется посредством определений таблиц, привязанных к уровню столбцов.

В SQL Server 2008 с помощью TDE производится шифрование данных, журнала и архивных файлов все базы данных. Это не позволяет злоумышленнику получить доступ к файлам базы данных и закрепить их за другим экземпляром SQL Server. Файлы шифруются с использованием сертификата: только он открывает доступ к базе данных. По мере записи/считывания страниц данных или файлов журнала осуществляется шифрование/дешифрование. Данные в кэше SQL Server представляют собой обычный текст, в то время как данные на диске хранятся в зашифрованном виде.

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

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

Вход в систему

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

В базах данных Oracle существуют три типа пользователей.

  • Владельцы схем - пользователи, которые создают объекты, относящиеся к приложению, и управляют ими.
  • Пользователи приложений - пользователи (или системы), работающие с данными из таблиц владельцев схем
  • Административные пользователи - пользователи, осуществляющие специальные функции; это администраторы базы данных или администраторы системы безопасности.

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

Пользователей SQL Server можно разделить на те же категории, что и в Oracle.

  • Владельцы схем - пользователи, которые создают объекты, относящиеся к приложению, и управляют ими.
  • Пользователи приложений - пользователи (или системы), работающие с данными из таблиц владельцев схем.
  • Административные пользователи - пользователи, осуществляющие специальные функции; это администраторы базы данных или администраторы системы безопасности.

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

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

Особые пользователи категории «dbo» (владелец базы данных) имеются во всех базах SQL Server и обладают соответствующими привилегиями на определенные действия в рамках БД. Административный логин sysadmin сопоставляется в каждой базе данных с пользователем dbo. Эти процедуры можно рассматривать как идентичные входу пользователя в базу данных Oracle в качестве SYSDBA или SYSOPER, при котором происходит автоматическое подключение в качестве SYS. Логины в SQL Server также могут сопоставляться с пользователем dbo в БД, обеспечивая его административными привилегиями в рамках данной базы.

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

Проверка подлинности - это процесс подтверждения того, что логин или имя пользователя, введенные пользователем для подключения к базе данных, принадлежат зарегистрированному пользователю. Как в Oracle, так и в SQL Server допускается проверка подлинности посредством операционной системы и на уровне базы данных (сервера). В SQL Server режим операционной системы называется Windows Authentication, а режим базы данных - SQL Server Authentication.

Расширенные методы обеспечения безопасности в Oracle поддерживают следующие способы проверки подлинности:

  • Kerberos;
  • RADIUS;
  • SSL;
  • Entrust/PKI.

В SQL Server поддерживается проверка подлинности Kerberos в рамках установки домена Windows Server® Active Directory®. Для поддержки проверки подлинности Kerberos в SQL Server могут быть сконфигурированы конечные точки.

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

Кроме того, ОС Windows поддерживает шифрование с использованием протокола безопасности IPsec, которое конфигурируется в рамках самой операционной системы за пределами SQL Server. Предусмотрены три метода проверки подлинности на базе IETF-стандартов, обеспечивающих безопасный обмен данными между компьютерами. Все приведенные ниже типы шифрования поддерживаются Windows:

  • аутентификация Kerberos v5.0, обеспечиваемая доменом Windows;
  • подписи открытых/закрытых ключей с использованием сертификатов;
  • пароли, временные, заранее распространяемые ключи проверки подлинности, которые используются исключительно для обеспечения безопасности соединения, а не для защиты пакетов данных приложений.

Пароли

Управление паролями в Oracle поддерживает следующие функции:

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

Поскольку архитектура безопасности SQL Server служит для усиления функций безопасности Windows, она плотно интегрирована с механизмами проверки подлинности и авторизации Windows. В связи с этим при использовании проверки подлинности Windows в SQL Server можно извлечь преимущества, предоставляемые такими функциями, как защита паролем, состав пароля, срок действия пароля и учетной записи, количество неверных вводов и усложнение шифрования. Проверка подлинности еще более усилена в SQL Server 2008. В SQL Server используется NetValidatePasswordPolicy API, которая стала доступна в версии Windows Server 2003. Это позволяет ужесточить политику паролей на компьютере, где запускается SQL Server.

Для дополнения функции безопасности SQL Server именами пользователей предусмотрены следующие возможности:

  • CHECK_POLICY;
  • CHECK_EXPIRATION;
  • MUST_CHANGE.

Эти параметры задаются при помощи инструкции CREATE LOGIN DDL или посредством SQL Server Management Studio.

Масштабируемость и высокая доступность ресурсов

Масштабируемость служит для поддержки сверхбольших баз данных (VLDB) и (или) OLTP большого объема. Размер VLDB зависит от размера нескольких крупных таблиц или большого числа мелких таблиц, либо от того и другого. Масштабируемость OLTP измеряется по количеству пользовательских соединений, времени реагирования и количеству обрабатываемых транзакций.

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

В следующих разделах рассматриваются некоторые функции масштабирования Oracle и SQL Server: от внутреннего обеспечения и структур и до важных компонентов.

Динамическое управление памятью

В Oracle и SQL Server можно динамически изменять компоненты, что обеспечивается соответствующими пулами памяти, и таким образом управлять рабочими нагрузками. Это снижает вероятность разбивки памяти на страницы. В SQL Server производится высвобождение всей неиспользуемой памяти по запросу операционной системы, после чего эта память включается в список свободных ресурсов. Если операционная система не использует всю память для собственных нужд или нужд других приложений, то SQL Server по мере необходимости резервирует память в своем буфере. В SQL Server минимальное количество памяти, необходимой для выполнения запроса, может определять пользователь. Ее объем варьируется от 512 КБ до 2 ГБ для каждого запроса.

Параллельные инструкции SQL

Параллельные инструкции SQL динамически подразделяются на отдельные задачи, распределяемые среди нескольких процессоров. Эти параллельные операции:

  • поддерживаются в симметричной многопроцессорной обработке (SMP), обработке с массовым параллелизмом (МРР) и кластерных системах;
  • обеспечивают выигрыш в производительности при обработке запросов, создании указателей, операциях массивной обработки данных (DML и загрузки данных), агрегировании, копировании и создании таблиц с помощью инструкции SELECT INTO;
  • поддерживают внутри- и межоперационный параллелизм.

В Oracle и SQL Server имеются очень схожие архитектуры, используемые для выполнения параллельных операций SQL. Оптимизаторы Oracle и SQL Server используют подчиненные потоки (для запросов) и рабочие потоки (для осуществления схемы выполнения). В SQL Server степень параллелизма (DOP) определяется автоматически для каждого запроса - практически как в Oracle.

Операции прямой вставки

При осуществлении операции прямой вставки в Oracle данные таблицы добавляются к файлу данных, минуя кэш БД. Этой функцией можно воспользоваться при помощи инструкции INSERT и утилиты SQL*Loader. Операция прямой вставки работает в последовательном и параллельном режимах.

Все вставки в SQL Server должны проходить через кэш базы данных. Страницы памяти сбрасываются из буферов на диск через интервалы времени, заданные параметром CHECKPOINT, или в случае недостатка памяти.

Общие серверы (ранее - MTS)

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

Режим общего сервера является режимом по умолчанию в SQL Server. Поскольку SQL Server работает только в среде Windows, предусмотрено эффективное распределение соединений на уровне потоков или в режиме «волокон» (fiber mode). Эта особенность позволяет использовать SQL Server для обработки сотен и тысяч одновременных подключений пользователей.

Обновляемое распределение дискового пространства

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

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

Методы доступа

Для ускорения доступа к данным в Oracle предусмотрены индексы B*-tree (восходящие/нисходящие), побитовые индексы, индексы на базе функций, индексно-организованные таблицы, секционированные индексы, совместные индексы, совместные побитовые индексы и индексы обратного ключа.

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

Общее управление

Функция хранилища данных (Data Warehousing) в Oracle включает в себя механизмы создания, использования и динамического управления сводными таблицами, а также прозрачного изменения запросов на применение этих таблиц. Все процессы осуществляются при помощи интеллектуального механизма изменения запросов. Функция автоматически перенаправляет запрос в подчиненные таблицы для использования существующих сводных таблиц.

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

Блоки разных размеров

В Oracle поддерживаются блоки разных размеров (2 KБ, 4 KБ, 8 KБ, 16 KБ, 32 KБ) в рамках БД, с тем чтобы размещать объекты в нужном наборе файлов для повышения производительности ввода-вывода. Эта функция тонкой настройки ввода-вывода предполагает определенные операционные издержки, поскольку перемещение таблиц может затребовать полный спектр операций экспорта/импорта при перемещении табличных пространств с различными размерами блока.

В SQL Server используется блок фиксированного размера - 8 КБ. Несмотря на то, что это налагает на администратора ограничение в тонкой настройке ввода-вывода, такой подход повышает перемещаемость и автоматизацию соответствующих процессов. Фиксированный размер блока в SQL Server позволяет автоматизировать операции вводаВ SQL Server используется блок фиксированного размера – 8 КБ. Несмотря на то, что это налагает на администратора ограничение в тонкой настройке ввода-вывода, такой подход повышает перемещаемость и автоматизацию соответствующих процессов. Фиксированный размер блока в SQL Server позволяет автоматизировать операции ввода- 24 вывода и распределения памяти, поскольку точно известно, какое количество дискового пространства используется каждой операцией.

Внешние таблицы

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

SQL Server позволяет ссылаться на внешние источники данных через связанные серверы или с помощью команды OPENDATASOURCE.

Внешние файлы, в частности неструктурированные, считываются с помощью команды OPENROWSET (BULK…) из SQL Server Management Studio или посредством инструкций командной строки, вводимых в режиме SQLCMD в SQL Server Management Studio. Связанные серверы позволяют устанавливать соединения с различными источниками данных, включая электронные таблицы и текстовые файлы. Пользователь может самостоятельно осуществить вставку, обновление и удаление операций с помощью инструкций SQL в отношении этих источников данных.

RAC

Архитектура программного обеспечения Oracle Real Application Cluster (RAC) в контексте функций масштабирования обеспечивает высокую производительность и повышенную пропускную способность благодаря горизонтальному масштабированию БД с использованием кластеризованных серверов. Аппаратные узлы получают доступ к общей базе данных, формируют общие ресурсы дискового пространства и базы данных, используя при этом собственную память и процессорные мощности. Программное обеспечение RAC распределяет рабочую нагрузку между серверами. Новая технология Cache Fusion сводит к минимуму проблемы производительности благодаря переброске информации из одного кэша в другой (синхронизации).

В SQL Server используются федеративные серверы баз данных с распределенным секционированным представлением (DPV), что дает возможность расширения без привлечения общих ресурсов. Федеративные серверы БД распределяют нагрузку на процессоры в рамках группы серверов путем горизонтального деления данных в рамках БД SQL Server. Эти серверы управляются независимо друг от друга, но совместно обрабатывают запросы к базе данных.

Сегментирование таблиц

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

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

Все функции, относящиеся к сегментированию, на уровне таблиц и индексов доступны в SQL Server 2008 и Oracle.

Кроме того, SQL Server поддерживает секционированное представление – это представление UNION ALL горизонтально сегментированных данных, хранящихся в таблицах (в тех же или отдельных базах данных на тех же или других серверах). Такое представление создается для проверки ограничений, что схоже с секционированными представлениями, которые предлагались Oracle до появления технологии сегментирования.

Репликация

Репликация представляет собой отличный способ масштабирования приложений, особенно в рамках территориально-распределенной сети (WAN). Однако этот метод доступен лишь тогда, когда материализованные представления используются только для запросов. Тиражирование с несколькими основными репликами (Oracle) и одноранговая репликация (SQL Server) – это способы, обеспечивающие обновление данных на любом основном объекте. Эти технологии будут работать правильно при горизонтальной сегментации данных, изменяемых на каждом из объектов, со скорее асинхронным, нежели синхронным распространением. Репликация транзакций и репликация слиянием в SQL Server также позволяет передавать поток изменений от подписчика к издателю. Кроме того, репликация в SQL Server обеспечивает распространение изменений схемы.

Резервная база данных

В Oracle и SQL Server к масштабированию резервных баз данных относится функция, которая предполагает их использование только для чтения, что дает возможность снимать с рабочей БД ресурсоемкие операции, например создание отчетов и поддержку принятия решений. Логическая резервная база данных в Oracle позволяет создавать дополнительные объекты схемы, что повышает производительность подобных операций. В SQL Server резервная база данных и образ базы данных изменению не подлежат.

Поддержка AWE

Для SQL Server и Oracle на базе Windows могут быть включены расширения AWE, что позволяет им ссылаться на физическую память сверх лимита в 4 ГБ (в 32-битных системах).

Поддержка 64-битных систем

Архитектура 64-битных систем дает существенные преимущества с точки зрения оборудования и операционной системы, что положительно сказывается на возможностях масштабирования и производительности. С переходом от 8-битных систем к 16- и 32-битным эти преимущества ощущаются во все большей степени. Масштабируемость основывается на возможности использования 64-битной памяти или диапазона адресов в 16 миллионов ГБ. Размер файлов вырос с 2 ГБ в 16-битных системах до 4 ГБ в 32-битных и до 16 ЭБ в 64-битных файловых системах. Поскольку больший объем памяти вмещает больше данных, используется меньше обращений к диску, за счет чего снижается разбиение на страницы и подкачка и, как следствие, повышается производительность. Схожие преимущества обеспечиваются процессорами, осуществляющими 64-битные целочисленные операции и операции с плавающей точкой, что существенно повышает пропускную способность. Упоминаемые в этом документе количественные показатели являются по своей природе теоретическими. На практике размер памяти, доступной для прямого доступа, ограничен операционной системой и аппаратной архитектурой.

Единственным различием между Oracle и SQL Server 2008, использующими одно и то же основание кода для 32-битных и 64-битных версий ПО баз данных, является компиляция. Функциональность обеих версий идентична. SQL Server 2008 поддерживает работу с процессорами AMD 64-bit Opteron и Athlon 64, а также Intel Xeon с технологией EMT64. На 64-битных системах SQL Server допускает использование до 32 ТБ памяти. Кроме того, SQL Server поддерживает процессоры с технологией Hyper-Threading и многоядерные процессоры.

NUMA

SQL Server 2008 использует доступ к неоднородной памяти (NUMA). Основное преимущество архитектуры NUMA – масштабируемость. Архитектура NUMA позволила расширить границы архитектуры симметричной многопроцессорной обработки (SMP). В архитектуре SMP все возможности доступа к памяти сосредоточиваются на одной общей шине памяти. Этого достаточно для относительно небольшого количества процессоров. Проблемы с общей шиной появляются при работе с десятками или даже сотнями процессоров, которые соревнуются друг с другом за доступ к общей шине памяти. Эти узкие места позволяет преодолеть архитектура NUMA. С ее помощью ограничивается количество ЦП на одной конкретной шине памяти, а различные узлы (локальная или удаленная память) соединяются между собой посредством высокоскоростного соединения.

Сервисно-ориентированная архитектура

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

SQL Server Service Broker

В SQL Server 2005 была представлена технология SQL Server Service Broker, обеспечивающая функции для построения приложений на базе SOA. Service Broker обеспечивает:

  • устойчивую асинхронную модель программирования с использованием сервисов, очередей и бесед Service Broker (сообщения);
  • создание очередей и надежный обмен сообщениями с использованием очередей Service Broker.

Преимущества Service Broker можно использовать в приложениях и сохраненных процедурах (Transact-SQL или CLR). Как правило, приложение или сохраненная процедура направляет сообщение в службу Service Broker (этот процесс начинает беседу). Далее служба помещает сообщение в соответствующую очередь, а затем уже сама очередь активирует определенную сохраненную процедуру (которая выводит из очереди и обрабатывает сообщения). Сохраненная процедура используется для подтверждения сообщения и направления ответа приложению, а также для окончания беседы. Приложение получает ответ и завершает диалог. Service Broker обеспечивает инфраструктуру для надежной и безопасной маршрутизации сообщений, бесед, очередей, служб и их активации.

SQL Server Service Broker обеспечивает следующие преимущества.

  • Сообщения обрабатываются как транзакции SQL Server для обеспечения целостности данных.
  • Гарантируется однократная обработка сообщений в том же порядке.
  • Service Broker обеспечивает надежную доставку.
  • Беседы и данные сохраняются даже при перезагрузке системы, восстановлении сервера/экземпляра после отказа и сбоев сети.
  • Поддерживается гибкая и быстрая разработка приложений, благодаря интегрированной поддержке Service Broker в SQL Server Management Studio.
  • Простота мониторинга посредством счетчиков System Monitor и диагностических утилит.

Расширенные функции очередности потоков Oracle

Схожие с возможностями Service Broker функции предлагает Oracle Streams Advanced Queuing (AQ). В рамках Oracle Streams AQ создается очередь сообщений производителей. Приложения-потребители выводят сообщения из очереди. Подобные сообщения при создании очереди или выводе из очереди могут преобразовываться. Oracle Streams AQ обеспечивает необходимую поддержку функций ввода в очередь, вывода из очереди, распространения, преобразования, обеспечения безопасности, 28 создания расписания, контроля потоков и асинхронных уведомлений. Интегрированная среда обработки Oracle позволяет разрабатывать приложения на базе Oracle Streams AQ; в инструменты управления встроены функции контроля.

Заключение

Microsoft SQL Server 2008 является полноценным решением по управлению данными, которое предоставляет пользователям новые возможности. Это надежная, согласованная и производительная платформа для приложений по обработке глобальных данных и бизнес-аналитики. SQL Server 2008 продолжает линейку знакомых и высокопроизводительных программных средств от Microsoft. Решение предназначено для профессионалов в ИТ-сфере и конечных пользователей, которые стремятся к повышению ценности своего бизнеса за счет снижения совокупной стоимости владения (ТСО), простоты использования ПО с широкими возможностями интеграции. SQL Server 2008 повышает качество служб и инфраструктуры благодаря тому, что улучшает организацию бизнес-процессов за счет снижения издержек на разработку и интеграцию.

Ссылки для получения дополнительной информации:

https://www.microsoft.com/sqlserver/: сайт SQL Server

https://technet.microsoft.com/en-us/sqlserver/: Центр технической поддержки SQL Server

https://msdn.microsoft.com/en-us/sqlserver/: Центр разработки SQL Server

Оказался ли этот документ полезным для Вас? Просим Вас поделиться своим мнением. Как бы Вы оценили этот документ по шкале от 1 (плохо) до 5 (отлично), и что побудило Вас дать такую оценку? Пример:

  • Ваша высокая оценка связана с приведенным в документе актуальными примерами, отличными скриншотами, четкостью изложения или с другой причиной?
  • Ваша низкая оценка связана с плохими примерами, нечеткими скриншотами и невнятным изложением?

Ваши отзывы помогут нам повысить качество наших изданий. Отправить сообщение.