Рубрика «Администрирование баз данных» - 62

Несколько лет назад заказчик, крупный медицинский центр федерального значения, поручил нам разработать софт, обслуживающий информационные киоски. Внешне киоск напоминает платёжный терминал (только без купюроприёмника), его основная функция, как следует из названия, — предоставление пациентам различной информации, такой как расписание приёма врачей, услуги и их стоимость, и так далее.
По понятным причинам для киоска потребовалось разработать упрощённый интерфейс пользователя, который было решено реализовать как web-приложение. Имея в штате опытных web-программистов, уверенно владеющих php, решили (для скорости) поручить им его написание, организовав связь с базой данных нашей медицинской системы. Рассматривалось 3 варианта взаимодействия:

  • ODBC
  • JDBC
  • web-сервисы.

Web-программисты предпочли ODBC как наиболее простой с их точки зрения вариант, и альфа-версия киоска довольно быстро увидела свет. Однако вскоре выяснилось (surprise!), что php-код должен работать не под Windows, как это было у разработчика, а под Linux, несмотря на то, что в те годы наша медицинская система эксплуатировалась заказчиком на платформе Windows 2008. Чтобы «подружить» всех членов триады (Linux – ODBC-драйвер Caché — php5) потребовались определённые усилия. Последовательность проделанных действий я зафиксировал в виде наброска к данной статье, которую и предлагаю вашему вниманию.
Читать полностью »

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

Читать полностью »

image

В этом документе представлены рекомендации по миграции определений данных (схем) и данных в базу данных SQL Windows Azure. Эти рекомендации предназначены главным образом для однократного переноса с SQL Server в базу данных SQL. Сведения о совместном использовании данных и резервном копировании базы данных SQL см. в статье SQL Data Sync Overview (Обзор синхронизации данных SQL).

Факторы, которые следует учесть при миграции

Microsoft Windows Azure предоставляет несколько вариантов хранения данных. Можно выбрать один или несколько вариантов для использования в проектах.

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

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

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

Рассмотрим важность наличия гистограмм по колонкам с высокой степень неравномерности распределения данных в колонке.
Возьмем достаточно большую таблицу STG.TEST. Имеется неуникальный индекс TEST_I по полю FIELD_ID.

select count(*) from stg.test
-----------
43756707

SQL> desc stg.test;
Name        Type          Nullable Default Comments 
----------- ------------- -------- ------- -------- 
NAME CHAR(2)                                 
DAT   DATE                                    
ID     NUMBER(12)    Y                         
FIELD_ID    INTEGER                                 
FIELD_VALUE VARCHAR2(100) Y

Создадим неоднородность распределения данных в колонке FIELD_ID — проапдейтим колонку FIELD_ID, выставив значение=100 и несколько значений руками выставим=103, 1000, 1002, 1003 (для примера)

Читать полностью »

Как запускать DBDeploy в Gradle
В данной заметке я покажу, как запускать DBDeploy из скрипта Gradle.
Как запускать DBDeploy в Gradle

О чём это вообще?

Возможно, вы уже слышали о версионированной миграции структуры баз данных. Об этом писали на хабре. DBDeploy — один из самых простых и известных инструментов, позволяющий легко установить все последние изменения в базе данных на любом инстансе и любой девелоперской машине. А Gradle — модный ныне инструмент для сборки проекта (как Ant и Maven, только лучше). О нём тоже уже писали.

И в чём вопрос?

Вопрос в том, как запускать DBDeploy из скрипта Gradle? У DBDeploy есть таски для Ant и плагин для Maven, но пока ещё нет плагина для DBdeploy (точнее, он в зачаточном состоянии). Немного потыркавшись, я пришёл к выводу, что самый простой способ — это использовать тот самый Ant таск DBDeploy из скрипта Gradle (здесь описано, как из gradle-скрипта использовать любые Ant-таски). Рассмотрим пример.

Читать полностью »

В предыдущей части рассматривалась настройка зеркала — технологии высокой доступности InterSystems Database Mirroring СУБД Caché.
В этой статье будут рассмотрены сценарии плановых перерывов и отказов и реакция зеркала на них.
Читать полностью »

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

В первую очередь это видно по иску, который Oracle подала против IBM в отношении вводящей в заблуждение рекламы её машин баз данных Exadata. Грубо говоря, Oracle заявила, что ее софт работает в 20 раз быстрее, сравнивая некую идеальную конфигурацию на современном оборудовании у конкретного заказчика со средней абстрактной конфигурацией IMB. Ниже есть детали, но это как сравнить болид Формулы-1 и внедорожник, заявив, что внедорожник в 20 раз быстрее в лесу.

Что происходит с Oracle?

Национальная рекламная ассоциация (США) уже отклонила иск, но Oracle собирается обжаловать это решение.Читать полностью »

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

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

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

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

Сформированные файлы (db_info.txt с ДЕВа и такой же с ПРОДа) можно, в дальнейшем, сравнивать утилитами типа WinDiff и решить, где значение вернее и какое из них оставить.
Читать полностью »

За время работы администратором баз данных я выработал для себя одно правило, которого придерживаются многие DBA. Это «золотое» правило всех администраторов баз данных – не делай ничего серьезного с базой данных, если у тебя нет бэкапа. Если ты собрался серьезно изменить параметры базы данных, провести операции по техническому обслуживанию базы данных и т.п. – то всегда перед этим надо выполнить операцию резервного копирования. Этот принцип достаточно долго работал и оправдывал себя, и даже в нескольких случаях помогал восстановить базу данных на определенный момент времени.

Недавно перед нами была поставлена задача – разработать процедуру резервного копирования хранилища данных размером в 20 Терабайт. Используя наработанные практики резервного копирования, я попытался разработать такую процедуру и уложиться в то же время в рамки RPO (recovery point objective) и RTO (recovery time objective). Обе эти характеристики измеряются во времени и представляют собой следующее: RPO – допустимый объем возможных потерь данных, RTO – допустимое время простоя или за какое время база данных должна восстановиться. Вот тут-то и началось самое интересное – как бы я не прикидывал и не рассчитывал, но разработанная процедура резервного копирования никак не желала укладываться в эти рамки – слишком большой объем данных надо было забэкапить. В самом лучшем случае, с многочисленными оговорками и условиями база данных восстанавливалась за несколько часов, а такого бизнес себе позволить не мог. Хотя, у Сбербанка на этот счет несколько иное мнение и они считают, что клиенты могут и подождать. Но тут был не Сбербанк. В обычной же ситуации, когда на базу данных не налагались серьезные ограничения и условия, восстановление заняло бы несколько дней. Это усугублялось тем, что невозможно «снять» бэкап за приемлемое время – это также занимало несколько дней и создавало большую нагрузку на базу данных. Сразу оговорюсь, что эта база данных не поддерживает инкрементальный бэкап в текущей версии. Возможно, если бы мы могли получить инкрементальность, то игра и стоила бы свеч, и традиционная процедура резервного копирования имела бы право на жизнь в этом случае.

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

Уже не одна правильная статья написана про необходимость и преимущества хранения исходных кодов схем базы данных в системах контроля версий (типа CVS, SVN, TFS и др.), а также ведения deploy – скриптов.
Не стану повторяться, но разберем один специфических аспектов этого процесса.

Не секрет, что нормально поставленный процесс разработки состоит из собственно разработки(Dev), внутреннего тестирования(QA), приёмочного тестирования конечными пользователями (UAT) и, непосредственно, «Production». Детали жизненного цикла могут отличаться в индивидуальных случаях, но это не существенно для темы статьи.

Порой (а в опыте автора – часто) так случается, что окружения, на которых происходят разные этапы этого цикла могут отличаться по тем или иным причинам. Различия могут быть какие угодно. От разных tablespace-ов, до отличий в названиях схем, DBLink-ов и других индивидуальных особенностей. Как эффективно решить эту неприятность мы и рассмотрим в этой статье.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js