На что обратить внимание при миграции с Oracle на PostgreSQL

Столбцы при переходе с Oracle на PostgreSQL

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

Ограничения при переходе с Oracle на PostgreSQL

В обеих системах баз данных ограничения Primary и External Key, Check, Not-Null и Unique работают более или менее одинаково.

Идентификаторы при переходе с Oracle на PostgreSQL

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

Индексы при переходе с Oracle на PostgreSQL

B-tree и нисходящие индексы должны работать в PostgreSQL. Reverse keys, bitmap и join indexes в настоящее время не поддерживаются. Глобальный индекс не поддерживается в PostgreSQL.

Разделы при переходе с Oracle на PostgreSQL

Разделы Hash, List и Range должны работать в PostgreSQL после миграции.

Таблицы при переходе с Oracle на PostgresSQL

CREATE TABLE в основном совместим, за следующими исключениями:

В PostgreSQL отсутствуют глобальные временные таблицы. Вместо этого используйте временные таблицы (LOCAL TEMP).

Параметры предложения хранения (INITRANS, MAXEXTENTS) не распознаются в Postgres и должны быть удалены.

Для параметра Oracle PCTFREE замените его фактором заполнения PostgreSQL.

Топ 5 преимуществ работы с облачными провайдерами

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

Доступ к широкому спектру квалифицированных сотрудников

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

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

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

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

24x7x365 поддержка по доступной цене

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

Делегируйте нам «рутинную» работу

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

Работа с провайдерами облачных сервисов

Зачастую у поставщиков управления облачными сервисами очень тесный контакт с провайдерами облачных технологий. Это означает, что мы из первых рук получаем информацию о новых технологиях и тренинги по ним.
Так же мы участвуем в программах бюджетирования от провайдеров, с помощью которых мы можем снижать стоимость миграции для клиента!
DBI на сегодняшний день является ключевым партнером для таких облачных провайдеров, как: Oracle, Microsoft, Amazon и IBM.
Так же в нашей команде более 20 сотрудников являются сертифицированными специалистами в области облачных технологий.

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

Основное преимущество работы с профессиональными поставщиками управления облачными сервисами является автоматизация развертывания облачной инфраструктуры, с использованием подхода «Инфраструктура как код» (англ. Infrastructure-as-Code; Iac). Это подход для управления и описания инфраструктуры через конфигурационные файлы и скрипты, без необходимости взаимодействовать с графическим интерактивным интерфейсом облачного провайдера или вручную редактировать множество конфигураций на серверах.

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

  • RedHat – Ansible
  • PuppetLabs– Puppet Enterprise, Relay
  • Hashicorp– Terraform, Packer, Vault и т.д.
  • GitHub– GitHub Enterprise, GitHub Actions
  • Microsoft– Azure DevOps pipelines, ARM templates, Azure Blueprints & policy и т.д
  • AWS– AWS CodePipelines, CloudFormation
Если вы заинтересованы и готовы вступить в ряды тех, кому мы помогаем делать их бизнес лучше, пожалуйста, свяжитесь с нами.

Технические долги

Большинство компаний сталкиваются с огромным количеством технических «долгов» во время миграции в облако.
В этой статье мы рассмотрим 5 путей как DevOps может помочь их решить.

Что такое технический «долг»?

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

К примеру, плохо описанный процесс управления состоянием (state management) может сильно усложнить горизонтальное расширение. Перед тем как расширять структуру вам придется переписать ту часть кода, которая отвечает за управление состоянием. Это и называют техническим «долгом».

Так же технические «долги» встречаются и в операционной деятельности.
Все еще работаете на Windows Server 2008, or Ubuntu 11.04 которые не поддерживаются производителем?
Не установили последний патч по безопасности? Это и есть технический «долг».

Как DevOps может помочь?

Создайте DevOps команду

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

Простые советы для борьбы с техническими «долгами»

Во-первых, нужно замечать и следить за техническими «долгами» в своем продукте.

Во время работы над продуктом помечайте (в Jira, Azure DevOps или Git) не оптимальные элементы как «techDebt». И выделять время в каждом спринте на эти задачи.
Мы советуем начать с 20% времени, выделяемого на спринт.

После этого в рамках ретроспективной работы с каждой командой оцените текущий уровень ваших технических «долгов». Если большинство оценит эту проблему высоко, то стоит увеличить количество часов в спринте на работу с «долгами», до того момента пока «долги» не перестанут мешать корректной работе продукта.

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

Построение общих сервисов самообслуживания

Все чаще компании создают общие сервисы для поддержки команд ответственных за продукты. Платформы основанные, на таких сервисах помогают избегать технических «долгов» при построении цепочек компонентов. Такие сервисы должны быть созданы в соответствии с запросами разработчиков и лучшими практиками для создания таких систем. Они могут быть, как сторонними SaaS-решениями, так и полностью собственными решениями.

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

Немного о InnerSource

В определении InnerSource от InnerSource Commons говорится «консолидирует опыт развития open source решений для помощи внутреннего развития компании».
Команды, работающие с платформой, должны быть ключевой точкой изменений и быть готовым к ним. Репозитории с кодом должны быть общедоступны и любой желающий может внести изменения после согласования с управляющей командой.

Автоматизация

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

Как автоматизация может помочь с техническим «долгом»

Для примера возьмем процесс управления инфраструктурой и на его примере рассмотрим, как «инфраструктура как код» и «конфигурация как код» помогут нам в борьбе с техническим «долгом».

Несовместимые системы — это наиболее часто встречающийся вариант технического «долга». Когда ваше приложение работает в среде разработки, но не работает ни в препроде ни в проде чаще всего причиной будет несовместимость систем. Это могут быть как настройки ОС или приложения, так и тысячи межсервисных настроек, с которыми работает приложение. И то время, которое вы тратите на устранение этой проблемы и есть стоимость вашего технического «долга».

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

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

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

Контейнеры для упрощения внедрения и управления приложением

Что такое контейнеры и как они могут помочь?

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

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

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

Использование DevOps для построения API-ориентированной модели

Модель с использованием микросервисов это один из возможных вариантов реализации API-центрированной модели. Глава Amazon Джеф Безос поставил задачу своим сотрудникам пользоваться только API при взаимодействии с системой под угрозой увольнения.
Конечно, в вашей организации все может быть не так сурово. Тем не менее поощрение команды работать с API четко определенных версий, это хороший метод для ухода от технических «долгов». Чаще всего «долги» копятся из-за разных методов доступа приложений к сервисам и данным, которые не соответствуют друг другу. К примеру, команда А читает данные из таблицы созданной командой Б. И если команда Б поменяет схему для своих нужд, то этим они непреднамеренно нарушат интеграцию с приложением команды А.

API делают эти зависимости гораздо более заметными и менее уязвимыми. Каждый продукт должен придерживаться опубликованного API с понятными дорожными картами и политикой изменений. Если на поздних стадиях нужна смена API, то выпускают новую версию, и определяется время, которое будет поддерживаться «старая».

Системы DevOps, к примеру CI/CD практика непрерывной интеграции и непрерывного развертывания кода обеспечивает сквозную прослеживаемость от юзер стори до реализации, а также позволяет разработчикам работать быстрее с меньшими рисками и с меньшими техническими долгами.
Если вы контролируете и помечаете места с техническими «долгами», как обсуждалось ранее, вы увидите результат достаточно быстро. А автоматизация процесса поможет сконцентрироваться на нуждах потребителя.

Миграция данных из коммерческих СУБД в СУБД PostgreSQL

Задачи, решаемые при миграции данных из коммерческих СУБД в PostgreSQL?

Уменьшение стоимости владения: помимо затрат на лицензии, использование коммерческих СУБД влечет за собой дополнительные расходы на платные опции. PostgreSQL  же – работает с открытым исходным кодом и его можно установить и использовать бесплатно.

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

Улучшение настраиваемости: поскольку PostgreSQL имеет открытый исходный код, существует бесчисленное множество расширений и надстроек, которые могут заметно улучшить производительность базы данных.

Какие преимущества есть у PostgreSQL перед коммерческими СУБД?

Прикладное программирование:

Коммерческие СУБД и PostgreSQL предоставляют API-приложение для связи с базой данных. Однако PostgreSQL является Open Source, поэтому разработчики могут напрямую получать доступ к любому компоненту PostgreSQL, просто включив файл заголовка в свой проект.

Аутентификация:

Коммерческие СУБД имеют встроенную систему аутентификации. PostgreSQL же использует host-based аутентификацию и, следовательно, может поддерживать широкий спектр методов аутентификации. Это обеспечивает большую гибкость аутентификации и возможность делегировать процесс.

Расширяемость:

Коммерческие СУБД в основном имеют  проприетарную систему подключаемых модулей, тогда как система расширений PostgreSQL поддерживается широким сообществом, поэтому доступны тысячи подключаемых модулей.

Какие преимущества есть у PostgreSQL?

Языки:

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

Локализация:

Системные службы локализации PostgreSQL встроены для обеспечения автоматической кодировки символов и поддержки сопоставления.

Производительность:

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

Масштабируемость:

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

Фазы миграции данных с коммерческих СУБД в PostgreSQL

Миграция данных состоит из следующих этапов:

  • Аудит системы (оценка совместимости, архитектуры и кода приложения)
  • Принятие решения на основе Аудита
  • Развертывание стенда для миграции
  • Конвертация данных и кода
  • Миграция схемы
  • Тестирование функциональности и оптимизация структур хранения и кода
  • Тестирование производительности и её оптимизация
  • Принятие решения о миграции
  • Миграция данных
  • Техническая поддержка Системы после Миграции

8 причин для миграции в облако

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

Основные 8 причин для миграции:

  • Снижение затрат на IT
  • Гибкость рабочих процессов
  • Повышение уровня безопасности
  • Решение проблем с устаревшим оборудованием
  • Консолидация дата центров
  • Предоставление возможности цифровой трансформации
  • Ускорение развития
  • Использование преимуществ новых технологий

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

Снижения затрат на IT

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

Гибкость рабочих процессов

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

Повышение уровня безопасности

Безопасности всегда уделяется особое внимание. С миграцией в облако, компания может модернизировать IT инфраструктуру согласно самым современным практикам и максимально защитить свой бизнес от кибер-угроз.

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

Решение проблем с устаревшим оборудованием

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

Консолидация дата центров

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

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

Ускорение развития

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

Использование преимуществ новых технологий

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

Процесс миграции в облако

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

1. Оценка готовности миграции (MRA)
2. Подготовка и планирование миграции (MRP)
3. Миграция

В 1й фазе важно ответить на следующие вопросы:

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

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

Миграция в AWS с DBI

За последние годы мы помогли нашим клиентам и партнёрам успешно мигрировать в AWS используя МАР подход.

DBI запускает бесплатный практикум по SQL

Сделай первый шаг в ИТ с DBI. Уже в начале июля стартует бесплатный практикум по SQL для начинающих.

✅От тебя нужно немного времени, много желания и ноутбук.
✅Техническое образование, знание английского языка и любой опыт в IT приветствуется.
✅Этот практикум для тебя, если ты закончил уже 2-3 курс или хочешь сменить сферу деятельности на IT.

Наш Практикум SQL, основанный на 15 летнем опыте работы с крупнейшими компаниями по всему миру, откроет для тебя возможность в дальнейшем получить востребованную профессию в мире IT.

Освоив данный курс SQL, ты сможешь претендовать на вакансии в DBI:

  • BI разработчик
  • Аналитик
  • ETL разработчик
  • Консультант-разработчик ERP-систем
  • PL/SQL Разработчик
  • Администратор баз данных


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

Наш куратор в определенные дни будет доступен для офлайн консультаций и разбора заданий в Точке кипения ЮФУ.

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

Для регистрации нужно пройти по ссылке и заполнить форму https://forms.gle/4zzFrdRuCkREt4VK9.

Мы обязательно свяжемся с тобой!

#dbi #sql #it #database #cloud #db #обучениеSQL

Компания DBI приняла участие в онлайн-мероприятии

25 мая компания DBI приняла участие в онлайн-мероприятии «Oracle Analytics. Новые возможности и опыт практической миграции с Oracle BI». Спикеры, специалисты Oracle Александр Бернадский и Наталья Кусова, а также директор по региональному развитию DBI Алексей Захаров, рассказали о преимуществах аналитических решений, ребрендинге линейки программных продуктов Business Intelligence, а ещё поделились кейсами по миграции на новые версии.

Программа мероприятия:

  • 00:00 Представление участников. Чем продукты Oracle Analytics Service отличаются друг от друга, что нового появилось в последних версиях.
  • 6:40 Как много клиентов уже мигрировало на новое семейство продуктов (из опыта компании DBI)?
  • 18:41 Многие клиенты пользуются предыдущей версией BI. Какой функциональности нового релиза они лишены?
  • 27:33 Насколько эти функции востребованы в реальных проектах?
  • 32:13 Поддерживает ли инструмент экспорт Excel?
  • 01:04:47 Опыт DBI. Более детально о подходе к проектам миграции.

Демо.

  • 43:35 Демонстрация использования мультитабличных наборов данных

 

Новые возможности и опыт практической миграции с Oracle BI

Запись трансляции можно посмотреть по ссылке: https://www.youtube.com/watch?v=PgvFg5g3my0

#oracle #cloud #dbi #analytics #data

Финансовый контроль во время «короны»: чего ожидать?

«Корона» и финансовый комплаенс: нужны новые подходы и технологии?

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

Как именно — в статье Алексея Захарова немецкому журналу Red Stack