«Технологический центр Дойче Банка — это структура для IT-поддержки глобального бизнеса банка» — Александр Халухин
Предлагаем вашему вниманию свежий выпуск интервью с ведущими мастер-классов на PG Day'17 Russia. Сегодня мы побеседовали с Александром Халухиным, разработчиком баз данных Oracle с 10-тилетним стажем. Александр профессионально занимается разработкой уже более 12-ти лет. Последние четыре года своей карьеры посвятил разработке крупных проектов для технологического центра Deutsche Bank в Москве.
На PG Day'17 Russia Александр представит интенсивный практический курс по диагностике производительности Oracle Database.
Александр поведал нам о внутренних инициативах технологического центра, проекте, над которым сейчас трудится, объяснил сложности миграции крупных банковских продуктов на альтернативные решения для хранения данных и, конечно же, дал краткий анонс предстоящего мастер-класса.
Александр: В разработке — с 18 лет, именно тогда состоялась моя первая постоянная работа за зарплату. Текущая специализация сейчас — это PL/SQL Oracle. Занимаюсь этим на постоянной основе более десяти лет. Начинал, как и многие приходящие в Oracle в те годы, со всевозможных сред быстрой разработки Delphi и C++ Builder. За свою карьеру успел поработать в разных местах. В настоящий момент работаю в Технологическом Центре Дойче Банка.
PG Day: Расскажи подробнее, чем занимаются и какие задачи решают в Технологическом Центре Дойче Банка?
Александр: Технологический Центр Дойче Банка — это самостоятельная структура для IT-поддержки глобального бизнеса банка во всевозможных его сферах. Департамент, в котором я работаю, — это валютные операции, FX-рынок.
Как известно, у Дойче Банка несколько центров разработки, находящихся в разных точках мира: в Соединенных Штатах, Румынии, Индии, и самый крупный — в России (Москва и Петербург). В Технологических Центрах происходит разработка новых продуктов, а также поддержка существующих решений.
PG Day: Я знаю, что в Технологическом Центре периодически возникают различные инициативы, исследования. Что это за инициативы, принимают ли в них участие специалисты, работающие с базами данных? Если да, то в каком качестве?
Александр: Действительно, со стороны бизнеса есть запрос на инновацию. Часто бывает, что бизнес видит картину по-своему, а IT специалисты — по-своему. Искать точку приложения сил, возможные оптимизации всегда следует совместно. Бизнес может предложить, как снизить затраты, понять неоптимальность бизнес-процессов, а айтишники — подсказать, как это лучше всего сделать с точки зрения технологий. Поэтому инициативы действительно приветствуются.
В моем домене среди коллег достаточно большое количество случаев, когда они приходили к бизнесу и говорили: «Давайте откажемся от этого и этого — сохраним деньги на обслуживание оборудования и оплату лицензий покупного софта. Заменим вот этим — оно разрабатывается и живо». Если находится какая-то неоптимальность, которая позволяет заменить несколько программных продуктов на один, то точка приложения сил будет применена к нему, чтобы всё было более гибким и эффективным.
Я работаю в команде разработки баз данных одного из самых высоконагруженных проектов, который считает риски в торговле. Мы также тесно работаем с бизнесом. Вот, например, сейчас происходит достаточно крупный проект миграции на Exadata. Такая миграция позволит серьезно сократить затраты, обеспечить задел для дальнейшего роста и решить много накопившихся проблем.
PG Day: К слову о миграциях и технологиях. Можешь пояснить, что такое Exadata, какие цели вы преследуете такой миграцией? Какие задачи пытаетесь решить?
Александр: Exadata — это название продукта Oracle, который представляет собой проприетарную «железку». Это стойкий сервер со специально заточенным хранилищем и крутящимся на нем Oracle-кластером. Это кластерная СУБД. В чем преимущества и недостатки такого решения? Преимущество — в том, что все от одного разработчика, а значит очень простая поддержка. В случае возникновения смежных проблем между «железом» и софтом не надо разрываться между тремя-четырьмя вендорами: производителями «железа», операционной системы, драйверов для storage или самого storage, СУБД. Все это обслуживается из одного источника. К тому же, это высокотехнологичные решения, обладающие очень хорошей производительностью. Они заточены под использование в качестве такого сервера СУБД высокопроизводительной машины.
Минус — это дороговизна. К сожалению, не всем оно доступно, не такое широкое коммьюнити. Хотя, это та же самая СУБД, тот же Oracle RAC, только на особенном железе.
Это будет мой первый опыт с кластерными базами, но по сути это то же самое, что мы можем встретить на других кластерных решениях от Oracle с одной только разницей, что здесь эта «железка» работает с ним несколько более оптимизировано, позволяет делать всякие интересные вещи. Например, фильтрацию данных во время запроса. Если есть какой-то предикат (самый простой случай — SELECT * FROM имя_таблички и какой-то набор предикатов), то фильтрация лишних записей будет происходить уже на уровне хранилища, они не будут даже доходить до операционной системы.
PG Day: В чем выгода миграции? И что является наибольшим испытанием для тебя в этом процессе? Для кого-то это код переписать, для кого-то — данные смигрировать без даунтайма…
Александр: Первая очевидная польза от миграции — в том, что мы получаем пространство для дальнейшего роста по производительности. Далее, любой большой старый проект — это как корабль, который много лет ходит по морям, оброс ракушками ниже ватерлинии. Так вот, подобного рода архитектурные миграции дают повод срезать всю лишнюю коросту, «ракушки», устроив дополнительную ревизию того, кто наши клиенты, с какими системами взаимодействуем. Особенность проекта, в котором я сейчас работаю, — это достаточно старая большая система, которая взаимодействует с несколькими сотнями других систем. Часть этих систем находится на финальных шагах жизненного цикла, а часть, наоборот, только начинается. Это такая скала в бурлящем море, в котором все ориентируются на тебя.
Основная выгода — немного привести эту «скалу» в порядок. А испытание, абсолютно точно ты подметил, — это большое количество внешних систем, с которыми нужно взаимодействовать и обеспечивать «бесшовную» миграцию. Потому что понятно, что мы не имеем ни морального, ни физического права заставить всех окружающих разработчиков, сотрудников службы поддержки в едином порыве с нами делать изменения для этой миграции. Поэтому это очень сложный, большой и скоординированный синхронный процесс подготовки всех систем или каких-то групп этих систем и выделения общих паттернов использования. Помимо нескольких сотен внешних систем, с которыми мы взаимодействуем (информационная система в общем понимании), есть еще такое же количество приложений, запускающихся на машинах конечных пользователей. Это тоже достаточно большой «зоопарк». Перечисленные испытания — все наши.
PG Day: Есть ли тенденции в сторону инноваций в вашем ТехЦентре? Смотрят ли ваши разработчики и инженеры в сторону других решений (может быть, кластерных или NoSQL) или же вы сфокусированы только на платформе Oracle?
Александр: Безусловно, мы оцениваем различные решения. Но хорошо, что наш бизнес понимает, что подобного рода выбор — это всегда палка о двух концах. С одной стороны, получаешь преимущества, с другой — недостатки. Это всегда баланс между сохранением работающих отлаженных процессов и потенциальной выгодой получения чего-то улучшенного ценой нестабильности.
В нашем проекте в свое время было сделано историческое решение в пользу Oracle, и мы до сих пор об этом ничуть не пожалели. Достаточное количество бизнес-логики находится в базе, и мы используем если не все, то добрые 95% всех фич, которые предлагает Oracle как коммерческая СУБД. В то же время есть запросы от бизнеса на производительность и проекты особого рода, где не нужна полноценная коммерческая операционная СУБД. Там, где это достижимо и уместно, у нас используются NoSQL-решения. У меня, к сожалению, не так много экспертизы в этой области, чтобы более подробно об этом рассказать.
PG Day: На твой взгляд, есть ли у бизнеса такого уровня, как банкинг, перспектива функционировать с применением новых альтернативных решений? Или всегда будет место только крупным коммерческим штукам вроде Oracle? Я знаю, что сейчас есть прецеденты, появляются новые решения. Многие разработчики заявляют, что они по пропускной способности, количеству транзакций в секунду способны соревноваться с промышленными коммерческими базами.
Александр: Как шутят, возможно встретить и динозавра. Вполне реально, что какой-то открытый софт или нереляционные СУБД могут вытеснить классических коммерческих монстров типа Oracle, SQL Server, Teradata в банкинге. Это произойдет, как только они станут достаточно стабильными как в работе, так и в поддерживаемом API, обрастут хорошим слоем инструментов разработки и диагностики, сформируют достаточное коммьюнити и техническую поддержку с вменяемым SLA.
Как я понимаю из своего опыта работы, банки имеют достаточное количество legacy-софта, обеспечивающего их основную жизнедеятельность. Переход с него на что-то более современное, с лучшей производительностью и функционалом осложнен не столько технологически, сколько организационно. Казалось бы, нам ничего не стоит смигрировать данные, написать новый софт по взаимодействию с этими данными. Но де-факто мы столкнемся с тем, что придется переучивать пользователей, службу техподдержки, нужно будет учесть необъятное количество систем, которые с тобой взаимодействуют. Технически всё реализуемо, а практически — это работа, которая вне сферы разработчика.
У нас в некоторых новых проектах уже применяются NoSQL-решения как альтернатива стандартным реляционным СУБД.
PG Day: В продолжение разговора о твоей экспертизе в области Oracle как СУБД: какие фичи есть у Oracle, которые отличают его от других решений в области хранения данных?
Александр: Топ-фич, которыми я восхищаюсь в Oracle, — это его отличные встроенные инструменты диагностики, это то количество информации, которую он предоставляет тебе о том, что в нем происходит. Ввиду того, что довольно много времени приходится заниматься не только разработкой, но и поддержкой существующих решений, отладкой производительности, оптимизацией, то не знаю, что бы я делал в отсутствие этих инструментов. Так, например, насколько я знаю, в PostgreSQL это достаточно острая проблема, инфраструктура инструментов диагностики там проработана недостаточно хорошо.
В Oracle так: если есть задача, значит, для нее имеется стандартный инструмент. Если нет стандартного инструмента, можно сделать композицию из нескольких других инструментов, чтобы достичь того же результата. Я не столько фанатею от новых функциональных возможностей, чем он тоже славится, сколько от того, насколько он хорошо инструментирован.
PG Day: Что, на твой взгляд, можно усовершенствовать в Oracle?
Александр: Тут я не буду оригинальным — качество самого саппорта. Так как я работаю в проекте, где используется большое количество различных технологий, у меня была возможность сравнить саппорты многих разработчиков. Я до сих пор под большим впечатлением от саппорта, который предоставляет DELL. Это компания, купившая QUEST, который раньше делал известный многим Toad, SQL Navigator, Shareplex (продукт для репликации данных времен «до покупки GoldenGate Oracle'ом»). Среди всех компаний-разработчиков, с которыми мне удалось столкнуться, DELL, или как минимум та часть команды, которая поддерживает продукты Quest, — эталон для IT-саппорта. Это очень отзывчивые люди.
Им можно позвонить в любое время дня и ночи, и они найдут инженера, который будет до победного решать с тобой проблему. К сожалению, я не вижу такого рвения, такого хорошего качества оказываемых саппорт-услуг со стороны Oracle. Меня это повергает в некоторое уныние, потому что я знаю, что банк платит достаточно большие деньги за лицензии. Это не наша уникальная проблема, не только наша «головная боль». Думаю, что многие «ораклисты», которым когда-либо приходилось взаимодействовать с Oracle-саппортом, имеют такие же жалобы. Если удастся выйти на инженера второго-третьего уровня, который будет отталкиваться от типовых вопросов и пытаться что-то предлагать, — с этого начинается хороший саппорт. Но, к сожалению, чтобы этого добиться, с тебя «стрясут» неимоверное количество диагностики и прочего, что не будет иметь ничего общего с проблемой, которую описываешь.
PG Day: Расскажи немного про мастер-класс, который ты проведешь на конференции летом на PG Day. Он посвящен диагностике производительности Oracle Database. Какие вопросы ты планируешь рассматривать, чем руководствовался, когда составлял план мастер-класса?
Александр: Мастер-класс будет посвящен вопросам диагностики, в первую очередь, диагностике проблем с производительностью. Среди всего спектра проблем, с которыми приходится сталкиваться разработчикам и сотрудникам поддержки, они наименее очевидны. С функциональными проблемами яснее: есть баг, нашли проблему в коде и починили. Когда проблема какая-то мелькающая или она произошла в прошлом — у нас, возможно, не хватает диагностики для этого, и мы не были достаточно подготовлены.
На встрече расскажу обо всем, что является общей проблемой в других СУБД и чем я восхищен в Oracle. Свой рассказ построю на основании личного опыта и собственных подходов в диагностике.
Постараюсь преподнести всё в форме живого интерактива, который не только приоткроет завесу в мир диагностических возможностей Oracle, но и даст вполне конкретный практический опыт по использованию этих диагностических средств для преодоления проблем. Затрону в первую очередь то, что потребляет больше всего времени у разработчика и саппортера. Расскажу, как в Oracle диагностировать проблемы и бороться с ними. Какие паттерны и подходы в диагностике можно использовать и транспонировать из Oracle в PostgreSQL, идеологически наиболее близкую к Oracle в плане архитектуры СУБД.
PG Day: Спасибо, Александр!
На PG Day'17 Russia Александр представит интенсивный практический курс по диагностике производительности Oracle Database.
Александр поведал нам о внутренних инициативах технологического центра, проекте, над которым сейчас трудится, объяснил сложности миграции крупных банковских продуктов на альтернативные решения для хранения данных и, конечно же, дал краткий анонс предстоящего мастер-класса.
Александр: В разработке — с 18 лет, именно тогда состоялась моя первая постоянная работа за зарплату. Текущая специализация сейчас — это PL/SQL Oracle. Занимаюсь этим на постоянной основе более десяти лет. Начинал, как и многие приходящие в Oracle в те годы, со всевозможных сред быстрой разработки Delphi и C++ Builder. За свою карьеру успел поработать в разных местах. В настоящий момент работаю в Технологическом Центре Дойче Банка.
PG Day: Расскажи подробнее, чем занимаются и какие задачи решают в Технологическом Центре Дойче Банка?
Александр: Технологический Центр Дойче Банка — это самостоятельная структура для IT-поддержки глобального бизнеса банка во всевозможных его сферах. Департамент, в котором я работаю, — это валютные операции, FX-рынок.
Как известно, у Дойче Банка несколько центров разработки, находящихся в разных точках мира: в Соединенных Штатах, Румынии, Индии, и самый крупный — в России (Москва и Петербург). В Технологических Центрах происходит разработка новых продуктов, а также поддержка существующих решений.
PG Day: Я знаю, что в Технологическом Центре периодически возникают различные инициативы, исследования. Что это за инициативы, принимают ли в них участие специалисты, работающие с базами данных? Если да, то в каком качестве?
Александр: Действительно, со стороны бизнеса есть запрос на инновацию. Часто бывает, что бизнес видит картину по-своему, а IT специалисты — по-своему. Искать точку приложения сил, возможные оптимизации всегда следует совместно. Бизнес может предложить, как снизить затраты, понять неоптимальность бизнес-процессов, а айтишники — подсказать, как это лучше всего сделать с точки зрения технологий. Поэтому инициативы действительно приветствуются.
В моем домене среди коллег достаточно большое количество случаев, когда они приходили к бизнесу и говорили: «Давайте откажемся от этого и этого — сохраним деньги на обслуживание оборудования и оплату лицензий покупного софта. Заменим вот этим — оно разрабатывается и живо». Если находится какая-то неоптимальность, которая позволяет заменить несколько программных продуктов на один, то точка приложения сил будет применена к нему, чтобы всё было более гибким и эффективным.
Я работаю в команде разработки баз данных одного из самых высоконагруженных проектов, который считает риски в торговле. Мы также тесно работаем с бизнесом. Вот, например, сейчас происходит достаточно крупный проект миграции на Exadata. Такая миграция позволит серьезно сократить затраты, обеспечить задел для дальнейшего роста и решить много накопившихся проблем.
PG Day: К слову о миграциях и технологиях. Можешь пояснить, что такое Exadata, какие цели вы преследуете такой миграцией? Какие задачи пытаетесь решить?
Александр: Exadata — это название продукта Oracle, который представляет собой проприетарную «железку». Это стойкий сервер со специально заточенным хранилищем и крутящимся на нем Oracle-кластером. Это кластерная СУБД. В чем преимущества и недостатки такого решения? Преимущество — в том, что все от одного разработчика, а значит очень простая поддержка. В случае возникновения смежных проблем между «железом» и софтом не надо разрываться между тремя-четырьмя вендорами: производителями «железа», операционной системы, драйверов для storage или самого storage, СУБД. Все это обслуживается из одного источника. К тому же, это высокотехнологичные решения, обладающие очень хорошей производительностью. Они заточены под использование в качестве такого сервера СУБД высокопроизводительной машины.
Минус — это дороговизна. К сожалению, не всем оно доступно, не такое широкое коммьюнити. Хотя, это та же самая СУБД, тот же Oracle RAC, только на особенном железе.
Это будет мой первый опыт с кластерными базами, но по сути это то же самое, что мы можем встретить на других кластерных решениях от Oracle с одной только разницей, что здесь эта «железка» работает с ним несколько более оптимизировано, позволяет делать всякие интересные вещи. Например, фильтрацию данных во время запроса. Если есть какой-то предикат (самый простой случай — SELECT * FROM имя_таблички и какой-то набор предикатов), то фильтрация лишних записей будет происходить уже на уровне хранилища, они не будут даже доходить до операционной системы.
PG Day: В чем выгода миграции? И что является наибольшим испытанием для тебя в этом процессе? Для кого-то это код переписать, для кого-то — данные смигрировать без даунтайма…
Александр: Первая очевидная польза от миграции — в том, что мы получаем пространство для дальнейшего роста по производительности. Далее, любой большой старый проект — это как корабль, который много лет ходит по морям, оброс ракушками ниже ватерлинии. Так вот, подобного рода архитектурные миграции дают повод срезать всю лишнюю коросту, «ракушки», устроив дополнительную ревизию того, кто наши клиенты, с какими системами взаимодействуем. Особенность проекта, в котором я сейчас работаю, — это достаточно старая большая система, которая взаимодействует с несколькими сотнями других систем. Часть этих систем находится на финальных шагах жизненного цикла, а часть, наоборот, только начинается. Это такая скала в бурлящем море, в котором все ориентируются на тебя.
Основная выгода — немного привести эту «скалу» в порядок. А испытание, абсолютно точно ты подметил, — это большое количество внешних систем, с которыми нужно взаимодействовать и обеспечивать «бесшовную» миграцию. Потому что понятно, что мы не имеем ни морального, ни физического права заставить всех окружающих разработчиков, сотрудников службы поддержки в едином порыве с нами делать изменения для этой миграции. Поэтому это очень сложный, большой и скоординированный синхронный процесс подготовки всех систем или каких-то групп этих систем и выделения общих паттернов использования. Помимо нескольких сотен внешних систем, с которыми мы взаимодействуем (информационная система в общем понимании), есть еще такое же количество приложений, запускающихся на машинах конечных пользователей. Это тоже достаточно большой «зоопарк». Перечисленные испытания — все наши.
PG Day: Есть ли тенденции в сторону инноваций в вашем ТехЦентре? Смотрят ли ваши разработчики и инженеры в сторону других решений (может быть, кластерных или NoSQL) или же вы сфокусированы только на платформе Oracle?
Александр: Безусловно, мы оцениваем различные решения. Но хорошо, что наш бизнес понимает, что подобного рода выбор — это всегда палка о двух концах. С одной стороны, получаешь преимущества, с другой — недостатки. Это всегда баланс между сохранением работающих отлаженных процессов и потенциальной выгодой получения чего-то улучшенного ценой нестабильности.
В нашем проекте в свое время было сделано историческое решение в пользу Oracle, и мы до сих пор об этом ничуть не пожалели. Достаточное количество бизнес-логики находится в базе, и мы используем если не все, то добрые 95% всех фич, которые предлагает Oracle как коммерческая СУБД. В то же время есть запросы от бизнеса на производительность и проекты особого рода, где не нужна полноценная коммерческая операционная СУБД. Там, где это достижимо и уместно, у нас используются NoSQL-решения. У меня, к сожалению, не так много экспертизы в этой области, чтобы более подробно об этом рассказать.
PG Day: На твой взгляд, есть ли у бизнеса такого уровня, как банкинг, перспектива функционировать с применением новых альтернативных решений? Или всегда будет место только крупным коммерческим штукам вроде Oracle? Я знаю, что сейчас есть прецеденты, появляются новые решения. Многие разработчики заявляют, что они по пропускной способности, количеству транзакций в секунду способны соревноваться с промышленными коммерческими базами.
Александр: Как шутят, возможно встретить и динозавра. Вполне реально, что какой-то открытый софт или нереляционные СУБД могут вытеснить классических коммерческих монстров типа Oracle, SQL Server, Teradata в банкинге. Это произойдет, как только они станут достаточно стабильными как в работе, так и в поддерживаемом API, обрастут хорошим слоем инструментов разработки и диагностики, сформируют достаточное коммьюнити и техническую поддержку с вменяемым SLA.
Как я понимаю из своего опыта работы, банки имеют достаточное количество legacy-софта, обеспечивающего их основную жизнедеятельность. Переход с него на что-то более современное, с лучшей производительностью и функционалом осложнен не столько технологически, сколько организационно. Казалось бы, нам ничего не стоит смигрировать данные, написать новый софт по взаимодействию с этими данными. Но де-факто мы столкнемся с тем, что придется переучивать пользователей, службу техподдержки, нужно будет учесть необъятное количество систем, которые с тобой взаимодействуют. Технически всё реализуемо, а практически — это работа, которая вне сферы разработчика.
У нас в некоторых новых проектах уже применяются NoSQL-решения как альтернатива стандартным реляционным СУБД.
PG Day: В продолжение разговора о твоей экспертизе в области Oracle как СУБД: какие фичи есть у Oracle, которые отличают его от других решений в области хранения данных?
Александр: Топ-фич, которыми я восхищаюсь в Oracle, — это его отличные встроенные инструменты диагностики, это то количество информации, которую он предоставляет тебе о том, что в нем происходит. Ввиду того, что довольно много времени приходится заниматься не только разработкой, но и поддержкой существующих решений, отладкой производительности, оптимизацией, то не знаю, что бы я делал в отсутствие этих инструментов. Так, например, насколько я знаю, в PostgreSQL это достаточно острая проблема, инфраструктура инструментов диагностики там проработана недостаточно хорошо.
В Oracle так: если есть задача, значит, для нее имеется стандартный инструмент. Если нет стандартного инструмента, можно сделать композицию из нескольких других инструментов, чтобы достичь того же результата. Я не столько фанатею от новых функциональных возможностей, чем он тоже славится, сколько от того, насколько он хорошо инструментирован.
PG Day: Что, на твой взгляд, можно усовершенствовать в Oracle?
Александр: Тут я не буду оригинальным — качество самого саппорта. Так как я работаю в проекте, где используется большое количество различных технологий, у меня была возможность сравнить саппорты многих разработчиков. Я до сих пор под большим впечатлением от саппорта, который предоставляет DELL. Это компания, купившая QUEST, который раньше делал известный многим Toad, SQL Navigator, Shareplex (продукт для репликации данных времен «до покупки GoldenGate Oracle'ом»). Среди всех компаний-разработчиков, с которыми мне удалось столкнуться, DELL, или как минимум та часть команды, которая поддерживает продукты Quest, — эталон для IT-саппорта. Это очень отзывчивые люди.
Им можно позвонить в любое время дня и ночи, и они найдут инженера, который будет до победного решать с тобой проблему. К сожалению, я не вижу такого рвения, такого хорошего качества оказываемых саппорт-услуг со стороны Oracle. Меня это повергает в некоторое уныние, потому что я знаю, что банк платит достаточно большие деньги за лицензии. Это не наша уникальная проблема, не только наша «головная боль». Думаю, что многие «ораклисты», которым когда-либо приходилось взаимодействовать с Oracle-саппортом, имеют такие же жалобы. Если удастся выйти на инженера второго-третьего уровня, который будет отталкиваться от типовых вопросов и пытаться что-то предлагать, — с этого начинается хороший саппорт. Но, к сожалению, чтобы этого добиться, с тебя «стрясут» неимоверное количество диагностики и прочего, что не будет иметь ничего общего с проблемой, которую описываешь.
PG Day: Расскажи немного про мастер-класс, который ты проведешь на конференции летом на PG Day. Он посвящен диагностике производительности Oracle Database. Какие вопросы ты планируешь рассматривать, чем руководствовался, когда составлял план мастер-класса?
Александр: Мастер-класс будет посвящен вопросам диагностики, в первую очередь, диагностике проблем с производительностью. Среди всего спектра проблем, с которыми приходится сталкиваться разработчикам и сотрудникам поддержки, они наименее очевидны. С функциональными проблемами яснее: есть баг, нашли проблему в коде и починили. Когда проблема какая-то мелькающая или она произошла в прошлом — у нас, возможно, не хватает диагностики для этого, и мы не были достаточно подготовлены.
На встрече расскажу обо всем, что является общей проблемой в других СУБД и чем я восхищен в Oracle. Свой рассказ построю на основании личного опыта и собственных подходов в диагностике.
Постараюсь преподнести всё в форме живого интерактива, который не только приоткроет завесу в мир диагностических возможностей Oracle, но и даст вполне конкретный практический опыт по использованию этих диагностических средств для преодоления проблем. Затрону в первую очередь то, что потребляет больше всего времени у разработчика и саппортера. Расскажу, как в Oracle диагностировать проблемы и бороться с ними. Какие паттерны и подходы в диагностике можно использовать и транспонировать из Oracle в PostgreSQL, идеологически наиболее близкую к Oracle в плане архитектуры СУБД.
PG Day: Спасибо, Александр!