|
|
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Была такая тема "Будущее профессии Oracle DBA" но загнулась , я на нее наткнулся пока искал по форуму по Cloud. Будущее профессии Oracle DBA Хотел немного оживить , узнать мнение других людей ну и рассказать свое видение если кому интересно. в силу специфики работы , я в курсе что происходит как в штатах так и на территории Австралии / Новой Зеландии. 1) Ну так вот , я 4 года назад не поверил в то что Cloud будет так востребован , сыграли остатки российского менталитета если хотите. Ну какой банк отдаст свою базу в Cloud думал я , на данный момент насколько я знаю все крупные банки AU/NZ перетаскиваю в Cloud свои системы, про банки в штатах не могу сказать , так как информацией не владею , но думаю ситуации аналогичная. Да конечно , все 100% баз они наверняка не перетащат , что то будет on Premises. 2) У моего клиента ситуация аналогичная , очень агрессивный вывод систем в Cloud. 3) Мониторинга рынка труда AU/NZ тоже дает весьма печальны данные , oracle dba позиции с 50-100 позиций 5-6 лет назад - до 5-10 позиций в месяц сейчас ( и это в хороший месяц , в районе конца-начала финансового года ). Тут речь идет только про город где я живу. В штатах рынок более веселый , но там и куда больше компаний, но так же идет decline по позиции oracle dba. 4) я бы еще добавил сюда вывод многих систем на оутсорс в Индию либо Индонезию, для РФ это пока не актуально и думаю не будет актуально еще много лет. 5) позиции Oracle DBA в компаниях будут все менее востребованными. Да, это было ясно еще 2-3 года назад и автор veep - это хорошо подметил в предыдущей теме - "Этой участь ждет не только Oracle DBA, а как мининум всех DBA (MSSQL,Mysql, и пр...) Сейчас все уходят в облака." )" Oracle DBA как профессия останется, но это будет как профессия конюха т.е. весьма специфична и редка если сравнивать с тем как это было в прошлом. Можно конечно сказать как "master_yoda" в прошлом топике - "Где они возьмут столько вменяемых ДБА?". Дело в том , что вменяемых DBA нужно будет сильно меньше , многие системы автоматизированы уже сейчас + продолжаются работы в этом направлении. Во многих компаниях сейчас норма 100 баз на одного DBA, у DBA из Amazon/Anure/Oracle в силу более высокой атоматизированности многих процессов эта цифра должна быть больше (кстати кто-нибудь знает сколько ?, интересно) В РФ в силу закрытости компаний и страны в целом , тенденции насколько я понимаю пока не так заметны. Просто интересно было бы узнать как обстоят дела там, так как связей в РФ у меня нет. Сорри за офтоп, просто было интересно узнать мнение народа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 16:27 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Мне 23 . Через неделю иду забирать диплом. Работаю DBA ( по крайней мере пытаюсь ) уже 4 месяца . Пожалуйста давайте не будем про то что это плохая и не востребованая должность . Я больше думаю что мало кто за такое возьмется . У нас в городе ( вот прямо сейчас проверил ) есть еще 5-6 компании которые примут на работу админа по ораклу , и такие обьявления висят месяцами . Я сам когда устроился ( опыта нуль ) мне сказали : - Мы ищем админа уже год , нам надоело. Возьмем тебя, если научишься оставим , нет вылетишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 16:46 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Dr. SYS, Про ЕС разговаривают вот здесь: http://www.sql.ru/forum/1297162-1/chto-proishodit-na-rynke-db-vakansiy-v-es ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 16:50 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Dr. SYS, тех кто не способен прокачаться в смежных направлениях, тех на обочину выкинет а норм чуваки просто переквалифицируются, хоть в сисадмины, хоть в прогеры ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 16:53 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
По моим ощущениям - RDBMS_NAME DBA-only действительно вымирают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 17:05 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
maverick2104У нас в городе ( вот прямо сейчас проверил ) есть еще 5-6 компании которые примут на работу админа по ораклу , и такие обьявления висят месяцами.Наверное те, кто решил связаться с ораклом на ближайшие N-лет, уже давно свалил из твоего городка на более интересные денежки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 17:12 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
AmKadmaverick2104У нас в городе ( вот прямо сейчас проверил ) есть еще 5-6 компании которые примут на работу админа по ораклу , и такие обьявления висят месяцами.Наверное те, кто решил связаться с ораклом на ближайшие N-лет, уже давно свалил из твоего городка на более интересные денежки. тоже вариант ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 17:13 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
AmKadНаверное те, кто решил связаться с ораклом на ближайшие N-лет, уже давно свалил из твоего городка на более интересные денежки. Начнем с того что я в столице ( не Россия ) так что тут самые интерессные деньги :) А в городе есть пара толковых админов ( компания приводила на консультацию ) только их ничтожно мало .... Просто я не знаю как в России но у нас никакому RDBMS не учат , даже основам , даже sql элементарному блин . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 17:22 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
maverick2104Начнем с того что я в столице ( не Россия )Тогда исправлюсь. AmKadНаверное те, кто решил связаться с ораклом на ближайшие N-лет, уже давно свалил из твоего городка твоей страны на более интересные денежки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 17:33 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
AmKadmaverick2104Начнем с того что я в столице ( не Россия )Тогда исправлюсь. AmKadНаверное те, кто решил связаться с ораклом на ближайшие N-лет, уже давно свалил из твоего городка твоей страны на более интересные денежки. Возможно. Но мне слабо верится что кто-то у нас ( по краиней мере из молодых ) решил связаться с Ораклом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 17:37 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Х.З. У меня впечатление, что subj забил большой и толстый на весь средний и малый бизнес с таким подходом, клиенты будут сваливать с него, как только представится возможность ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 18:53 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Временно забаненныйХ.З. У меня впечатление, что subj забил большой и толстый на весь средний и малый бизнес с таким подходом, клиенты будут сваливать с него, как только представится возможность и много кто из среднего и малого лицензии покупают? есть что терять? ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 19:01 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
DВАВременно забаненныйХ.З. У меня впечатление, что subj забил большой и толстый на весь средний и малый бизнес с таким подходом, клиенты будут сваливать с него, как только представится возможность и много кто из среднего и малого лицензии покупают? есть что терять? ))) 1) Немало, в том числе даже у нас. Отсуствие лицензии скорее исключение, чем правило. Без этой категории клиентов, интерес разработчиков к этой БД будет падатьSE1 - начальная цена 15k$, сейчас 220к$ (SE2 - можно не рассматривать). Посмотрите количество потенциальных клиентов, в зависимости от цены предложения. Будущие монстры бизнеса, востребованные новые продукты, автоматом уже не будут завязаны на эту компанию. Да и сейчас, новые проекты, уже стараются не завязывать конкретно на Oracle. 2) Большая клиентская база, позволяет сильно экономить на тестировании, что приведет (да и уже приводит) к падению качества кода. 3) Ну и "снятие сливок" с толстых клиентов - путь в один конец, примеров миллион: DEC, Novell, Sun ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 21:29 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Dr. SYSМожно конечно сказать как "master_yoda" в прошлом топике - "Где они возьмут столько вменяемых ДБА?". Дело в том , что вменяемых DBA нужно будет сильно меньше , многие системы автоматизированы уже сейчас + продолжаются работы в этом направлении. Автоматизируют диагностику в их всё больше и больше глючащих продуктах? Только теперь к этим продуктам добавились средства управления клаудом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 21:45 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Dr. SYS 5) позиции Oracle DBA в компаниях будут все менее востребованными. Да, это было ясно еще 2-3 года назад и автор veep - это хорошо подметил в предыдущей теме - "Этой участь ждет не только Oracle DBA, а как мининум всех DBA (MSSQL,Mysql, и пр...) Сейчас все уходят в облака." )" Классно быть пророком :) Хочу еще добавить что практика показывает что DBA прекрасно переучиваются на : 1) BI - Те же знания о данных, только более в практичной области ближе к бизнесу. 2) DevOps - Кодописание и автоматизация в любой области, в том числе в области DB 3) BigData - новое направление, которое нужно суппортить и не менее интересное. 4) Clouds - без коментариев. Так что если текущие спецы не ленивы, и не упертые как бараны, то в принципе ничего для них не изменится. P/s практика показывает что при должном уровне менеджмента и автоматизации даже средний DBA справляется с любой системой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 21:48 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
veep, А еще ДБА могут репортики клепать. Запросы уже знают, осталось только красиво отформатировать. HУ и с вебом примерно также. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2018, 22:34 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Тут надо смотреть какие задачи решает DBA в конкретной компании и какие проблемы компании решает Cloud. Если просто перетащить железку в облако, то для DBA разницы особой нет где крутится база. И здесь речь скорее "Свой ЦОД vs Cloud". Если DBA ставят SQL патчи руками в sqlplus, потому что такой процесс внедрения построен в системе, то перенеся БД в Cloud особо ничего изменится, патч по прежнему должен ставить какой-то человек, если не осилили перейти на liquibase и автодеплой этих скриптов. Ну ок, в случае автоматизации это может быть любой человек поддержки или разработки, знаний DBA тут не надо и человека очень легко заменить. Основная работа DBA это взаимодействие с людьми в этой же компании, направленное на эффективную работу ИТ-системы в целом: мониторинг ресурсов, которые жрет БД, разобраться почему стали жрать больше, посмотреть планы, пообщаться на тему роста нагрузки в перспективе, заказать новые железки, сделать бекапы, восстановление, грамотное секционирование, очистка мусора в БД (это надо пообщаться с людьми, узнать природу данных, можно ли их удалять или переносить в архивную БД) и т.д. В этом есть ценность человека - желание улучшать процессы в компании. В Cloud кто этим будет заниматься? Просто купим больше дисков, больше памяти, больше CPU. Прямо там человек будет сидеть и писать, что у вас 1 ТБ занимает TEMP_LOG, разберитесь, что за данные. Даже если напишет, то таблицу секционировать кто будет? Индус, который в душе не знает, что это за бизнес сущность? И вот это человеческое общение и знание данных, которые есть в БД в Cloud уже не перенести, потому что там нет такой услуги пока. А если вся твоя ценность в заведении руками учеток в базе, то с этим и скрипт справится. -- С другой стороны, сидеть годами с одной единственной экспертизой по Oracle Database даже как-то страшно, даже если сейчас есть работа. В любом случае если идти в смежное: контейнеры, девопс, автоматизация, программирование, сервера приложений, то выживаемость у такого бойца на рынке всяко будет лучше, чем голый Oracle. Чем больше админ способен продуктов поддерживать и понимать как они работают, тем лучше для него. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 00:40 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Wolverines, при переносе в CLoud с DBA снимаются задачи - установка патчей , бэкапы, частично оптимизация и практически вся настройка мониторинга ибо она встроенная , DBA только настраивает какие alerts хочет получать, dataguard теперь настраивается мышкой через пару менюшек , как добавить RAC я еще не видел но должго быть не сильно сложнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 01:13 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
master_yodaDr. SYSМожно конечно сказать как "master_yoda" в прошлом топике - "Где они возьмут столько вменяемых ДБА?". Дело в том , что вменяемых DBA нужно будет сильно меньше , многие системы автоматизированы уже сейчас + продолжаются работы в этом направлении. Автоматизируют диагностику в их всё больше и больше глючащих продуктах? Только теперь к этим продуктам добавились средства управления клаудом. master_yoda , для интереса посмотрите , какие сервисы дают тот же Oracle или Amazon cloud. Там снимается куча задач с DBA , да появляются немного новые по управлению сервисами в cloud но их не так мнго и они на мой взгляд проще (тыкаете мышкой по меню, а не занимаетесь настройкой конфиг файлов и.т.д.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 01:19 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
londiniumDr. SYS, Про ЕС разговаривают вот здесь: http://www.sql.ru/forum/1297162-1/chto-proishodit-na-rynke-db-vakansiy-v-es спасибо за наводку , почитаю, но тут дело не в географии - ЕС, РФ или Штаты , тренд общемировой , просто в некоторых регионах это более заметно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 01:24 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Dr. SYS, Что вы с этим уход в клауд носитесь? Уход в клауд это по сути перемещение БД с одного сервера на другой. Не из-за этого профессия Оракл ДБА изменяется/сжимается. Тут другие тенденции и их много, диссертацию можно написать, ИМХО ) В 2х словах - все течет все меняется) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 08:52 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Dr. SYSWolverines, при переносе в CLoud с DBA снимаются задачи - установка патчей , бэкапы, частично оптимизация и практически вся настройка мониторинга ибо она встроенная , DBA только настраивает какие alerts хочет получать, dataguard теперь настраивается мышкой через пару менюшек , как добавить RAC я еще не видел но должго быть не сильно сложнее. Сложность для DBA в установке патчей заключается не в вызове opatch apply или datapatch. Надо сходить обосновать зачем ставить патчи, договориться о тестировании, договориться о даунтайме, если он нужен, прочитать known issues. В облаке этим кто занимается? Бездумный патчинг в авторежиме не круто, у нас после патчевания обычно появляются новые проблемы, которых не было до. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 09:39 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Dr. SYSWolverines, при переносе в CLoud с DBA снимаются задачи - установка патчей , бэкапы, частично оптимизация и практически вся настройка мониторинга ибо она встроенная , DBA только настраивает какие alerts хочет получать, dataguard теперь настраивается мышкой через пару менюшек , как добавить RAC я еще не видел но должго быть не сильно сложнее. все делается для быстрейшей и полнейшей деградации DBA ))) Как в свое время деградировали бухгалтера, не способные теперь вне программы сделать проводку или свести баланс ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 14:05 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
DВАКак в свое время деградировали бухгалтера, не способные теперь вне программы сделать проводку или свести балансСледует ли из утверждения про деградацию, что бухгалтеров стало меньше или что на должность берут после 4х классов церковно-приходской школы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 14:24 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
-2-DВАКак в свое время деградировали бухгалтера, не способные теперь вне программы сделать проводку или свести балансСледует ли из утверждения про деградацию, что бухгалтеров стало меньше или что на должность берут после 4х классов церковно-приходской школы? они стали значительно дешевле а после "4х классов церковно-приходской школы " и дибиэей дофига )) я, например, педагог по образованию ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 14:28 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
DВАDr. SYSWolverines, при переносе в CLoud с DBA снимаются задачи - установка патчей , бэкапы, частично оптимизация и практически вся настройка мониторинга ибо она встроенная , DBA только настраивает какие alerts хочет получать, dataguard теперь настраивается мышкой через пару менюшек , как добавить RAC я еще не видел но должго быть не сильно сложнее. все делается для быстрейшей и полнейшей деградации DBA ))) Как в свое время деградировали бухгалтера, не способные теперь вне программы сделать проводку или свести баланс ) Хмм, смотря что тут считать деградацией. Что требует меньших навыков - владение 1С, или умение проводки вручную ? Люблю сравнение со сборкой автомобилей - раньше их собирали руками. Сначала на месте, потом на конвейере, теперь их собирают роботы. Сборщики либо превратились в операторов автоматизированной линии сборки, либо пошли искать другую работу. Весь ручной труд, где можно - его нужно автоматизировать и ДБА тут не исключение. Потому, что надо делать больше, за меньше времени. Это прогресс - эволюционируй или умри. Никто ж уже не считает бухгалтерию вручную на бумаге. Ничто не стоит на месте и это нормально и правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 15:04 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
kinky cat, все правильно прогресс социума = деградация отдельной личности )) ps никто не говорит что это не правильно, это не выгодно конкретно самим DBA )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 15:17 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Wolverinesесли не осилили перейти на liquibase и автодеплой этих скриптов.Ого, кто-то кроме меня с этого форума юзает эту технологию? Ничоси. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 15:22 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
имхо, основная причина отмирания в том, что щас логику в основном на аппсерверах реализуют, в базе только таблицы и индексы, и нахера платить ораклу, если, для таких целей, можно бесплатный мускуль или постгрис взять мой прогноз такой - крупные конторы, то бишь банки, госы, телеком, врятли резко спрыгивать с оракла будут, соответственно, дба в таких конторах никто их выгонять не будет, даже если в облако уйдут. но все новые проекты, будут стараться на бесплатном софте делать, а там выделенные дба - редкость а насчет деградации, так это в любой профессии. Как только рутины становится больше, чем новых скиллов, так считай - деградируешь зы коллеги сисадмины, рассказывали как один кадр, лет 10 назад, заявил им, что дескать, я - оракл дба, а не админ всякой фигни, типа сетки и оси таким дибиэям, свои понты, придется засунуть куда подальше, старожилам форума оракл тоже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 16:45 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинактаким дибиэям, свои понты, придется засунуть куда подальше, старожилам форума оракл тоже Только перед этим они будут долго ныть на уютненьком ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 16:57 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
и, кстати, с разрабами баз данных - то же самое на лигаси конешно останутся, но новых вакансий не будет т.к. биснес-логика в базе - это нынче моветон ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 17:05 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинаки, кстати, с разрабами баз данных - то же самое на лигаси конешно останутся, но новых вакансий не будет т.к. биснес-логика в базе - это нынче моветон Если вынос кода с из БД отменяет логику, то да. Если в приложении логика остается, то sql-работы только больше. Это все равно, что переписать статический sql в хранимом pl на dbms_sql. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 17:23 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
-2-казинаки, кстати, с разрабами баз данных - то же самое на лигаси конешно останутся, но новых вакансий не будет т.к. биснес-логика в базе - это нынче моветон Если вынос кода с из БД отменяет логику, то да. Если в приложении логика остается, то sql-работы только больше. Это все равно, что переписать статический sql в хранимом pl на dbms_sql. дальше своего носа не видишь в фейсбуке ни форин кей констрейнтов, ни джойнов в базе не делают все на серверах приложений общение с базой сводится к однотабличным селектам, однострочным инсертам и апдейтам И смысл в этом есть, т.к. масштабировать базу сложнее. Надо либо железо докупать либо мудрить с шардингом, кластерами и т.д., а сервера приложений тупо добавляются поэтому, все что можно делать вне базы, стараются делать вне базы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 17:45 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакпоэтому, все что можно делать вне базы, стараются делать вне базыАга. И данные тоже можно хранить мимо базы. Просто мега-паттерн на абсолютно всё случаи жизни. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 17:52 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Elicказинакпоэтому, все что можно делать вне базы, стараются делать вне базыАга. И данные тоже можно хранить мимо базы. Просто мега-паттерн на абсолютно всё случаи жизни. читать умеешь? казинак... щас логику в основном на аппсерверах реализуют, в базе только таблицы и индексы, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 17:54 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакчитать умеешь? казинак... щас логику в основном на аппсерверах реализуют,Слишком скромное мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 18:00 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинак .... общение с базой сводится к однотабличным селектам, однострочным инсертам и апдейтам ... ага, а потом приложения втянув в себя 16+ Гб данных из таблиц валятся с переполнением памяти ... а всего то надо было селектик написать и получить постранично (по 100 например) записей. Так нет жеж, мы все вытянем и в памяти быстро соберем/обработаем. Мы же однотабличные селекты делать умеем ... А еще можно пожаловаться что надо памяти докупить, это всегда проще чем код оптимизировать ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 18:27 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакзы коллеги сисадмины, рассказывали как один кадр, лет 10 назад, заявил им, что дескать, я - оракл дба, а не админ всякой фигни, типа сетки и оси таким дибиэям, свои понты, придется засунуть куда подальше, старожилам форума оракл тоже действительно, чего б сначала кабель не протянуть, а потом пойти и приклад не переписать ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 18:52 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
MaximaXXLказинак .... общение с базой сводится к однотабличным селектам, однострочным инсертам и апдейтам ... ага, а потом приложения втянув в себя 16+ Гб данных из таблиц валятся с переполнением памяти ... а всего то надо было селектик написать и получить постранично (по 100 например) записей. Так нет жеж, мы все вытянем и в памяти быстро соберем/обработаем. Мы же однотабличные селекты делать умеем ... А еще можно пожаловаться что надо памяти докупить, это всегда проще чем код оптимизировать ... сдуру конечно можно и хер сломать только никто не будет 16Гб тянуть из базы просто последовательно сделают сначала по параметрам с формы вытащат айди регионов, например, потом, айди наименований товаров а потом из таблицы транзакций вытащат нужные транзакции ну это к примеру ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 18:53 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинак, Я так на dbase и делал, когда еще CBO не придумали )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 19:28 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинак в фейсбуке ни форин кей констрейнтов, ни джойнов в базе не делают все на серверах приложений общение с базой сводится к однотабличным селектам, однострочным инсертам и апдейтам И смысл в этом есть, т.к. масштабировать базу сложнее. Надо либо железо докупать либо мудрить с шардингом, кластерами и т.д., а сервера приложений тупо добавляются поэтому, все что можно делать вне базы, стараются делать вне базыАга. Реализовали за пару месяцев на джавах констрейнты, ацид и получилось масштабируемо, а у дебилов из ораклов и айбиэмов не выходит вот уже сорок лет. И ни железа не требует, ни шардингов, ни кластеров... добавляется сервер в никуда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 21:00 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
авторбиснес-логика в базе - это нынче моветон А можно полюбопытствовать, что такое вообще "бизнес-логика"? Например, заведение депозитного договора - это "бизнес-логика" или нет? Если да, то кому мешает то, что в базе сидит процедура, которая открывает договор, счета и делает прочие операции ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 21:18 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинаксначала по параметрам с формы вытащат айди регионов, например, потом, айди наименований товаров а потом из таблицы транзакций вытащат нужные транзакции ну это к примеруТак это что, бизнес-логикой теперь называется? Это обычный фильтр на форме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2018, 22:38 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
londiniumавторбиснес-логика в базе - это нынче моветон А можно полюбопытствовать, что такое вообще "бизнес-логика"? Например, заведение депозитного договора - это "бизнес-логика" или нет? Если да, то кому мешает то, что в базе сидит процедура, которая открывает договор, счета и делает прочие операции Тссс.. не спугните сразу. Зачем с козырей ходить :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 01:09 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
-2-казинакв фейсбуке ни форин кей констрейнтов, ни джойнов в базе не делают все на серверах приложений общение с базой сводится к однотабличным селектам, однострочным инсертам и апдейтам И смысл в этом есть, т.к. масштабировать базу сложнее. Надо либо железо докупать либо мудрить с шардингом, кластерами и т.д., а сервера приложений тупо добавляются поэтому, все что можно делать вне базы, стараются делать вне базыАга. Реализовали за пару месяцев на джавах констрейнты, ацид и получилось масштабируемо, а у дебилов из ораклов и айбиэмов не выходит вот уже сорок лет. И ни железа не требует, ни шардингов, ни кластеров... добавляется сервер в никуда. между прочим это именно айбиэм и оракл двигают жаву а про сервер в никуда - ваще бред, не знаешь, так хоть не позорься ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 03:17 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
AmKadказинаксначала по параметрам с формы вытащат айди регионов, например, потом, айди наименований товаров а потом из таблицы транзакций вытащат нужные транзакции ну это к примеруТак это что, бизнес-логикой теперь называется? Это обычный фильтр на форме. просмотр договоров - такая же бизнес логика, как и заведение договоров, хотя если у вас свое понимание, то мне спорить неохото Хранимки не мешают, но ту ж самую функциональность можно и на жаве сделать, и это снизит нагрузку на базе. При одновременном выполнении в тысячах сессий хранимки грузят базу. Та же функциональность на жаве грузит аппсервер. Но добавить еще один аппсервер легко. А в базу ресурсы добавить геморно. Не будет многоэтажных запросов. Форин кей и чек констрейнты работают на аппсерверах. Снижается нагрузка на базу, и потребность в спецах по ораклу. И в таком случае, базу можно юзать бесплатную, и это основной аргумент в пользу отказа от оракла Но не стоит сцать. Лигаси в крупных конторах никуда не денется. Будет как с коболом. Вроде и устарел, но то, что на нем написано, не переписывают. Потому и спецы требуются. Правда, мало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 03:24 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакфункциональность можно и на жаве сделать, и это снизит нагрузку на базе.Наивный или заблужденец? казинакФорин кей и чек констрейнты работают на аппсерверах. Снижается нагрузка на базуСказочник, а патент есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 07:34 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Elicказинакфункциональность можно и на жаве сделать, и это снизит нагрузку на базе.Наивный или заблужденец? казинакФорин кей и чек констрейнты работают на аппсерверах. Снижается нагрузка на базуСказочник, а патент есть? это реальность, бро ща даже многие запросики до базы не долетают. Мелкие таблицы, типа справочников, во всяких мемкэшах и монгах кэшируются. но раз ты кроме оракла ничо не видел, тебе ничо не поможет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 07:48 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакща даже многие запросики до базы не долетают. Мелкие таблицы, типа справочников, во всяких мемкэшах и монгах кэшируются.В говно-свисто-перделках видимость всего может быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 08:35 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинак-2-Ага. Реализовали за пару месяцев на джавах констрейнты, ацид и получилось масштабируемо, а у дебилов из ораклов и айбиэмов не выходит вот уже сорок лет. И ни железа не требует, ни шардингов, ни кластеров... добавляется сервер в никуда.между прочим это именно айбиэм и оракл двигают жавуА БМВ двигают велосипеды. На замену своим же автомобилям, где узкое место водитель и пассажиры не масштабируются более положенных сидячих мест. Хотя... если ремни безопасности реализовать на уровне - держаться рукой за переднее кресло, можно на заднем сидении вместо трех и пятерых пассажиров посадить, а если вместо isofix применить коленки родителей, то еще двоих-троих детей ту да же. казинак-2-И ни железа не требует, ни шардингов, ни кластеров ... добавляется сервер в никуда.а про сервер в никуда - ваще бред, не знаешь, так хоть не позорьсяПоздно, уже опозорился. Для осознания "тупо добавить" у меня недостаточно квалификации. Пришлось воспользоваться документацией на сайте Томката. Смотрю раздел Apache Tomcat Clustering ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 09:19 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
-2-казинакпропущено... между прочим это именно айбиэм и оракл двигают жавуА БМВ двигают велосипеды. На замену своим же автомобилям, где узкое место водитель и пассажиры не масштабируются более положенных сидячих мест. Хотя... если ремни безопасности реализовать на уровне - держаться рукой за переднее кресло, можно на заднем сидении вместо трех и пятерых пассажиров посадить, а если вместо isofix применить коленки родителей, то еще двоих-троих детей ту да же. какое-то словесное недержание -2-казинакпропущено... а про сервер в никуда - ваще бред, не знаешь, так хоть не позорьсяПоздно, уже опозорился. Для осознания "тупо добавить" у меня недостаточно квалификации. Пришлось воспользоваться документацией на сайте Томката. Смотрю раздел Apache Tomcat Clustering ... ты походу кластер бд не отличаешь от кластера серверов приложений кластеру сервера приложений не надо consistency данных обеспечивать это просто дополнительный процесс, который перестартует упавшие/зависшие жава машины неохото мне ликбезом заниматься, читай доки елика, тоже с собой возьми ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 09:38 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакв фейсбуке ни форин кей констрейнтов, ни джойнов в базе не делают все на серверах приложений ..чушь тихонько повизгивала... Они всего лишь prestodb разработали, где практически ansi https://prestodb.io/docs/current/sql/select.html При том у них совсем другая задача - Big Data, логика относительно простая, но даже в ней они без sql и джойнов не обошлись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 10:20 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
kinky catказинакв фейсбуке ни форин кей констрейнтов, ни джойнов в базе не делают все на серверах приложений ..чушь тихонько повизгивала... Они всего лишь prestodb разработали, где практически ansi https://prestodb.io/docs/current/sql/select.html При том у них совсем другая задача - Big Data, логика относительно простая, но даже в ней они без sql и джойнов не обошлись. я там не работал, доказать не смогу, но первый же нагугленный линк говорит авторMySQL - используется как хранилище пар ключ-значение, никаких join'ов https://www.insight-it.ru/highload/2010/arkhitektura-facebook/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 10:30 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинак, учитесь для начала гуглить https://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/10151786197628920/?s=keen-io ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 10:33 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакMaximaXXLпропущено... ага, а потом приложения втянув в себя 16+ Гб данных из таблиц валятся с переполнением памяти ... а всего то надо было селектик написать и получить постранично (по 100 например) записей. Так нет жеж, мы все вытянем и в памяти быстро соберем/обработаем. Мы же однотабличные селекты делать умеем ... А еще можно пожаловаться что надо памяти докупить, это всегда проще чем код оптимизировать ... сдуру конечно можно и хер сломать только никто не будет 16Гб тянуть из базы просто последовательно сделают сначала по параметрам с формы вытащат айди регионов, например, потом, айди наименований товаров а потом из таблицы транзакций вытащат нужные транзакции ну это к примеру Ну если к примеру: Есть 2 таблицы: таб1 (Отдел, Сотрудник) - все сотрудники предприятия таб2 (Сотрудник, Время прихода/ухода) - только те сотрудники которые приходили ну и надо увидеть те отделы где на работу приходили все сотружники. Расскажите мне несведущему, как Вы его реализуете не делая объединение таблиц в одном селекте? И это ОЧЕНЬ простой пример ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 10:51 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
kinky catказинак, учитесь для начала гуглить https://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/10151786197628920/?s=keen-io ну меряться линками глупо но даже в вашем линке написано "The Presto system is implemented in Java" такшто, оракл бд там, какбэ нету, и ваш агрумент только подтверждает уменьшение потребности оракл админов и прогеров ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 11:06 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
MaximaXXLказинакпропущено... сдуру конечно можно и хер сломать только никто не будет 16Гб тянуть из базы просто последовательно сделают сначала по параметрам с формы вытащат айди регионов, например, потом, айди наименований товаров а потом из таблицы транзакций вытащат нужные транзакции ну это к примеру Ну если к примеру: Есть 2 таблицы: таб1 (Отдел, Сотрудник) - все сотрудники предприятия таб2 (Сотрудник, Время прихода/ухода) - только те сотрудники которые приходили ну и надо увидеть те отделы где на работу приходили все сотружники. Расскажите мне несведущему, как Вы его реализуете не делая объединение таблиц в одном селекте? И это ОЧЕНЬ простой пример элментарно в одну коллекцию тащим первую таблицу, в другую - вторую и объединяем коллекции ессно там наверняка фильтры будут, например, приходы/уходы за месяц да даже если не будут, объединяем и кэшируем, если надо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 11:08 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакMaximaXXLпропущено... Ну если к примеру: Есть 2 таблицы: таб1 (Отдел, Сотрудник) - все сотрудники предприятия таб2 (Сотрудник, Время прихода/ухода) - только те сотрудники которые приходили ну и надо увидеть те отделы где на работу приходили все сотружники. Расскажите мне несведущему, как Вы его реализуете не делая объединение таблиц в одном селекте? И это ОЧЕНЬ простой пример элментарно в одну коллекцию тащим первую таблицу, в другую - вторую и объединяем коллекции ессно там наверняка фильтры будут, например, приходы/уходы за месяц да даже если не будут, объединяем и кэшируем, если надо Вот и получаеться Вы тянете 16+ ГБ данных, вместо 2 строчек. А если сервера БД нахожятся в Маями а сервера приложений в Лондоне ... то лучше написать один правильный запрос чем укатывать сервера приложений ... с криками, добавте памяти То же относиться и к справочникам, иногда полезно иметь ин-мемори, но они должны быть не простыми (например, не нашел ин-мемори - полез в базу). Иначе кто-то добавит(а не дай бог исправит роутинг) в справочнике, а Вы об этом не знаете и по своей ин-мемори отправите транзакцию в другое приложение и разрушите бизнес логику. А это уже совсем плохо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 11:24 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакты походу кластер бд не отличаешь от кластера серверов приложений кластеру сервера приложений не надо consistency данных обеспечивать Ты путаешь социальную помойку с информационной системой. Если слетела подписка или странности с количеством лайков, всегда можно списать на руку Кремля или происки Госдепа. казинакэто просто дополнительный процесс, который перестартует упавшие/зависшие жава машины неохото мне ликбезом заниматься, читай докиДокументация томката clustering how-to пишет про репликацию сессий и предостерегает от "тупо добавил" для больших систем. казинакв одну коллекцию тащим первую таблицу, в другую - вторую и объединяем коллекции ессно там наверняка фильтры будут, например, приходы/уходы за месяц да даже если не будут, объединяем и кэшируем, если надоМногие здесь проходили это "объединяем" в эпоху beforesql на прогрессивном dbase. Но потом объемы подросли, требования усложнились и вложенный цикл (нестед-луп) перестал покрывать все потребности. Потом захотелось не тупить, когда данные меняют более одного пользователя, потом прочий acid ... и dbase сдулся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 11:36 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
MaximaXXLВот и получаеться Вы тянете 16+ ГБ данных, вместо 2 строчек. это с какого перепугу? применяем фильтры тащим из одной таблицы, отфильтрованное, а потом, по результатам первой, тащим из второй MaximaXXLТо же относиться и к справочникам, иногда полезно иметь ин-мемори, но они должны быть не простыми (например, не нашел ин-мемори - полез в базу). Иначе кто-то добавит(а не дай бог исправит роутинг) в справочнике, а Вы об этом не знаете и по своей ин-мемори отправите транзакцию в другое приложение и разрушите бизнес логику. А это уже совсем плохо кэши обновлять можно по требованию, то бишь после изменений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 11:37 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакMaximaXXLВот и получаеться Вы тянете 16+ ГБ данных, вместо 2 строчек. это с какого перепугу? применяем фильтры тащим из одной таблицы, отфильтрованное, а потом, по результатам первой, тащим из второй Да с такого, что Вы уже вытащили данные из 2-й таблицы чтоб их проанализировать (это уже более 2 строчек) А далее Вам надо вытащить все данные из первой, потому как Вы не можете из вытащенных данных сформировать полный фильтр, в класcике банальный Left Join без полных данных первой таблицы сложно организовать. Но и так, взяв данные из второй таблицы вы получаете НАМНОГО больше данных чем пришлет результирующий селект. казинакMaximaXXLТо же относиться и к справочникам, иногда полезно иметь ин-мемори, но они должны быть не простыми (например, не нашел ин-мемори - полез в базу). Иначе кто-то добавит(а не дай бог исправит роутинг) в справочнике, а Вы об этом не знаете и по своей ин-мемори отправите транзакцию в другое приложение и разрушите бизнес логику. А это уже совсем плохо кэши обновлять можно по требованию, то бишь после изменений Можно кеши обновлять "по требованию" но опять таки - Вы будете тянуть все данные, а их может быть не мало и тянете Вы их для того чтоб получить колекцию для работы с чем? Если с данными из базы (вытянутые другим селектом) то может разумнее написать 1 правильный селект, а не городить огород? Данные кеша обновляються не моментально... Ставить всех на холд для обновления кешей зачастую так себе практика. Я много лет работаю с джавистами и они осознали силу sql. Даже если им надо что-то на 1 фильтр (например отчет МОЖЕТ вытягянуть 10+ ГБ, потому что в форме чел может указать очень поверхносно фильтр) и джависты этого не делали раньше, они приходят и мы обсуждаем как лучше. Уже давно они отошли от практики вытянем все и в памяти все быстро сделаем. Хотя еще приходят "молодые дарования" которые мыслят аналогично Вашему, но лабы в институте и реальная работа это разные вещи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 12:22 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Как-то дискуссия не в то русло немного утекла. Начиналось все с вопроса про DBA и уход в cloud. А, еще почему-то автора интересует Россия хотя сам он там не обитает и контактов не имеет. Несколько моментов 1. Облака Действительно в западном мире ведется активный выход в облако (включая банковскую сферу и прочие sensitive data) и действительно это уже привело (и тренд продолжается) к уменьшению вакансий DBA. Еще Oracle продвигает свои мега-технологии под названием "the self-driving database" и "Oracle autonomous database", что призвано уменьшить число DBA... правда оно может и наоборот потребовать больше человеческих ресурсов, но в этом случае можно отключить (как некоторые типа меня делают с другими особо интеллектуальными технологиями типа cardinality feedback или adaptive plans). Возвращаясь к России, достаточно разумно что компании намного менньше ведуться на вывод своих данных в облако, владеемое юр лицом другой страны. 2. Удешевление железа и в частности оперативки + увеличение объемов данных. Предпринимается много попыток перенести базы в кластера, в частности хадуп. И это действительно приводит к уменьшению потребности в ораклистах, но есть несаолько моментов. Как бало замечено, надо полностью осознавать, что ACID не поддерживается (хотя дяди, выделяющие бюджеты ведутся на маркетинговый буллщит типа limited ACID support от чего в итоге страдают все). И, второе, даже когда пришло осознание что всякие хадупы не вариант для OLTP, то даже для DWH/OLAP возникают серьезные проблемы с масштабируемостью по нагрузке (число одновременно запущенных запросов по простому), а во вторых недопустимая latency. Внезапно обраруживается, что типичное время отзыва не конкурирует с аналогичной логикой в Оракле. И тут приходит новый тренд - кластер но уже в памяти. Что-то в духе гибрида GridGain + Hadoop . Как бы там ни было это таки сжимает долю Оракла. 3. Отупение среднестатистического специалиста. Этот тренд скомбинирован с пунктом 2. В общем ситуация такая: снижаются издержки на человеческий ресурс и на дорогое ПО типа Оракла и вместо этого вбухивается в железо. Никто особо не пытается понимать как работает оптимизатор запросов (про такое понятие как query transformations знает вообще наверное менее 5%), мало кто умеет нормально анализировать куда уходит время и ресурсы при обработке данных. Вместо этого давайте пытаться перейти на кластер, использовать разнообразные кеши и прочее... мало у кого взлетает. Люди которые были не в состоянии delivery on mature software вдруг терпят крах на сырых технологиях - внезапно! Но тенденция есть и долю Оракла это тоже уменьшает. 4. Жадность Ларри и замедленная приспособляемость к реалиям. Важный архитектурный недостаток Оракла - остуствие columnar storage. Это достаточно критично для больших хранилищ. Всякие hybrid columnar compressionна на то и гибрид, что это не полноценный колоночный формат. Вроде бы многообещающе выглядит in-memory column store, но влетает в копеечку. И на волне общего хайпа касательно хадупа, клстеров и прочих in-memory caches мало кто рассматривает инвестицию в Oracle in-memory option. Доля рынка на крупных хранилищах уходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 14:50 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
WolverinesВ этом есть ценность человека - желание улучшать процессы в компании. В Cloud кто этим будет заниматься? Просто купим больше дисков, больше памяти, больше CPU.Может в каком-то "Рога и копыта" у админа болит душа как сэкономить на железе, особено если он друг владельца или директора или имеет на этом фоне хорошие премии, но во всяких крупных бизнесах, которые являются основными потребителями Оракла есть DBA team и есть application team. application team смотрит насколько эффективно приложение потребялет ресурсы и насколько отзывчиво к пользователю. При переходе в облако ничего особо не меняется, если есть доступ к oracle performance views. А вот DBA team в принципе исчезает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 15:30 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopWolverinesВ этом есть ценность человека - желание улучшать процессы в компании. В Cloud кто этим будет заниматься? Просто купим больше дисков, больше памяти, больше CPU.Может в каком-то "Рога и копыта" у админа болит душа как сэкономить на железе, особено если он друг владельца или директора или имеет на этом фоне хорошие премии, но во всяких крупных бизнесах, которые являются основными потребителями Оракла есть DBA team и есть application team. application team смотрит насколько эффективно приложение потребялет ресурсы и насколько отзывчиво к пользователю. При переходе в облако ничего особо не меняется, если есть доступ к oracle performance views. А вот DBA team в принципе исчезает. А application team почему выживает?)) Приложеньки еще проще вынести, сам разработчик сразу после тестов деплоит контейнеры в облако. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 17:25 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Wolverines, application team это те, кто пишет приложение. Появление искусственного интеллекта, транслирующего невнятные хотелки пользователей в конкретный код я в ближайшем будущем не предвижу. Если же речь про вынесение логики из базы, то это даже неохота обсуждать. Но как я отметил основных тренда два 1. уменьшается доля ДБА из-за облака и разнообразных атоматизаций. Это влияет только на ДБА. 2. уменьшается доля Оракла в целом как из-за нездорового хайпа касательно новых подходов так и по некоторым объективным причинам. Это влияет и на разрабов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 18:15 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopWolverines, application team это те, кто пишет приложение. Ок, думал, что application team это люди, которые поддерживают апликейшен сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 19:20 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Меня приводит в легкое изумление доверчивость бизнеса к облакам. Отдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага". Полагаю, в данном случае скорее это вопрос веры и маркетинга. Веры в cloud-провайдеров с просветленными лицами, привнесенной в бизнес мессиями от маркетинга. Как полагаете, какой процент топ-менеджмента сможет провести параллель между переданными в облака базами и историей с гуглодоками, осознать наличие параллелей и задуматься о вечном? ...впрочем, за любым увлечением очередной новомодностью следует неизбежный откат. Не думаю, что DBA как профессия неизбежно отомрет в ближайшие годы. В конце концов, тем же клаудам нужны высокопрофессиональные администраторы, а это достигается планомерной селекцией, для которой необходима широкая "кормовая база" (или "поголовье" - кому как удобнее) администраторов обыкновенных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 20:29 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, жизненный цикл менеджмента обычно короче жизненного цикла компаний. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 00:12 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Железный конь идет на смену крестьянской лошадке. (С) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 04:25 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
-2-казинакты походу кластер бд не отличаешь от кластера серверов приложений кластеру сервера приложений не надо consistency данных обеспечивать Ты путаешь социальную помойку с информационной системой. Если слетела подписка или странности с количеством лайков, всегда можно списать на руку Кремля или происки Госдепа. опять понос -2-Документация томката clustering how-to пишет про репликацию сессий и предостерегает от "тупо добавил" для больших систем. двоюшник, то б хоть раз по делу чо написал а то только понос один ну какой смысл чота с тобой обсуждать? репликация сессий, блин, прочитал словечко и думаешь уел? даж не буду объяснять просто, я сам конфигурил веблоджики в кластер и без кластера а ты только отдельные фразы из доки выдергиваешь -2-казинакв одну коллекцию тащим первую таблицу, в другую - вторую и объединяем коллекции ессно там наверняка фильтры будут, например, приходы/уходы за месяц да даже если не будут, объединяем и кэшируем, если надоМногие здесь проходили это "объединяем" в эпоху beforesql на прогрессивном dbase. Но потом объемы подросли, требования усложнились и вложенный цикл (нестед-луп) перестал покрывать все потребности. Потом захотелось не тупить, когда данные меняют более одного пользователя, потом прочий acid ... и dbase сдулся. это ты типа в историю нас посвятил)) проблема твоя и тебе подобных в том, что вы даже не понимаете что есть альтернативные решения, сотворили себе кумира из оракла и обсираете тех, кому в принципе насрать на оракл ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 08:33 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousМеня приводит в легкое изумление доверчивость бизнеса к облакам. Отдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага". Полагаю, в данном случае скорее это вопрос веры и маркетинга. Веры в cloud-провайдеров с просветленными лицами, привнесенной в бизнес мессиями от маркетинга. Как полагаете, какой процент топ-менеджмента сможет провести параллель между переданными в облака базами и историей с гуглодоками, осознать наличие параллелей и задуматься о вечном? ...впрочем, за любым увлечением очередной новомодностью следует неизбежный откат. Не думаю, что DBA как профессия неизбежно отомрет в ближайшие годы. В конце концов, тем же клаудам нужны высокопрофессиональные администраторы, а это достигается планомерной селекцией, для которой необходима широкая "кормовая база" (или "поголовье" - кому как удобнее) администраторов обыкновенных.Точно, такие же мысли. Вот навернется Амазон из-за кассового разрыва, как Bear Sterns какой-нибудь или братья Леманы... И что будет с данными в AWS? Выключат нахрен и всё, а ещё лучше - продадут конкурентам чтобы, стало быть, покрыть убытки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 08:46 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Почитал я 3 страницы. Захотелось вступить в дискуссию. Вроде бы лет 10 назад пытались убить SQL? Привело к тому, что в каждой компании "ушедшей" от SQL родился собственный уродец а-ля SQL. Для выборки, агрегирования и сортировки данных. Компании подумали и вернулись обратно к SQL. Возможно облака ждет та же участь. Большая часть бизнеса уйдет в облака. Условно какой-нибудь Вася Пупкин будет сотрудником Амазона, но закреплен будет за компанией "Рога и копыта", базы которой будет администрировать. Собственно тот же ДБА, работающий на компанию "Рога и копыта", только вид сбоку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 18:46 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousОтдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага". Это не сильно отличается от передачи всего и вся в аутсорсинг. Арендуется у кого-то датацентр или место в нём. Берётся в лизинг железо. Нанимается подрядчик следить за системами. Разработка отдаётся вендору или его партнёру. Если бизнес согласен на это, то почему бы уже в клауд всё не сгрузить, чтобы минимизировать количество подрядчиков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 19:07 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
master_yodaandrey_anonymousОтдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага". Это не сильно отличается от передачи всего и вся в аутсорсинг. Арендуется у кого-то датацентр или место в нём. Берётся в лизинг железо. Нанимается подрядчик следить за системами. Разработка отдаётся вендору или его партнёру. Если бизнес согласен на это, то почему бы уже в клауд всё не сгрузить, чтобы минимизировать количество подрядчиков. Тогда уж приложение тоже в лизинг отдать, одно но Если сломается сетевой ms office - останется часть документов ( большинство в отправленных письмах) Если сломается безвозвратно база - компанию можно закрывать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 20:30 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
master_yoda, Учитывая лицензионное соглашение на cloud service, провайдер ничем сильно не рискует ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 20:31 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Vadim LejninЕсли сломается безвозвратно база - компанию можно закрывать В нашей конторе тоже поддались новомодным веяниям - перевели одну из систем в MS Azure. Проблемы начались сразу. После третьего падения системы подняли локальный сервер, скопировали туда базы системы и настроили процесс репликации из Azure в локальную базу. Теперь, если Azure ломается, просто переключаем систему на локальную базу. В чем смысл переводить базу в Azure - я не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2018, 18:09 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
flexgenПосле третьего падения системы подняли локальный сервер Что именно ломается и укладывается это в SLA? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2018, 18:21 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
подведем итоги - мы все умрем! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2018, 04:58 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Alexey Zhidkovподведем итоги - мы все умрем! :)Или сэволюционируем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2018, 11:18 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Можно еще под политическим углом посмотреть. Если хостинг-провайдер подчиняется санкционным законам то в одночасье ваши сервисы могут быть зобанены не смотря ни на какие SLA. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2018, 12:42 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousМеня приводит в легкое изумление доверчивость бизнеса к облакам. Помимо ответа Scott Tiger еще стоит добавить, что повышение эффективности, уменьшение затрат, обеспечение безопасности часто не ключевые факторы для принимающих решение о миграции. Большой бизнес - это большое число слоев. Любители математики могут почитать про модель Арнольда многоуровневого управления Многоступенчатое управление, описываемое нашей моделью при n > 3, неустойчиво. Двухступенчатое управление приводит к периодическим колебаниям, но не вызывает катастрофического нарастания колебаний, происходящего при трех- и более ступенчатом управлении. Настоящую устойчивость обеспечивает только одноступенчатое управление, при котором управляющее лицо более заинтересовано в интересах дела, чем в поощрении со стороны начальства. Реальность понятное дело, часто отличается от модели... еще и в худшую сторону. :) Мигрируют, как правило, не оперативные базы а хранилища. А хранилище это часто "вспомогательная вещь" не приносящая прибыли, а наоборот рассматриваемая как источник затрат. Кстати, неплохоя анализ был у Рудя, у него в центре внимания мелкософт, но это общей картины не портит - Облака, ит-про, будущее и бла бла бла . 4 года прошло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2018, 14:13 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Немного отвлекаясь от Оракла и крупных бизнесов, облака могут вполне иметь смысл. Как пример - back-end tools for mobile developers. Вот толковые ребята основали сервис ( Parse (platform) ) в 2011, а в 2013 продали его за $85 000 000 фейсбуку... который его похоронил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2018, 14:18 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
WolverinesЧто именно ломается и укладывается это в SLA?Что ломается в Azure я не знаю, не работаю с ним. В SLA не укладывались, система была недоступна от 4 до 6 часов, система должна работать 24*7. Как только переходили на локальный сервер БД - проблемы волшебным образом исчезали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2018, 20:54 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopА, еще почему-то автора интересует Россия хотя сам он там не обитает и контактов не имеет. Несколько моментов 4. Жадность Ларри и замедленная приспособляемость к реалиям. Важный архитектурный недостаток Оракла - остуствие columnar storage. Это достаточно критично для больших хранилищ. Всякие hybrid columnar compressionна на то и гибрид, что это не полноценный колоночный формат. Вроде бы многообещающе выглядит in-memory column store, но влетает в копеечку. И на волне общего хайпа касательно хадупа, клстеров и прочих in-memory caches мало кто рассматривает инвестицию в Oracle in-memory option. Доля рынка на крупных хранилищах уходит. спасибо за попытку вернуть тему в русло, а то уже все скатывалось в срач как обычно ) 1 - Автор прожил в РФ много лет ) ну из предыдущей темы заметил , что настроения в РФ почему то сильно оптимистичнее чем на западе. 2 - пункт 4, тут прямо в точку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2018, 03:27 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousМеня приводит в легкое изумление доверчивость бизнеса к облакам. а доверие тут не причем , финансовая сторона перетягивает. Вывод в cloud это большая экономия -> высвобождаются финансы для роста бизнеса (ну или на худой конец для солидных премий) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2018, 03:33 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Dr. SYSandrey_anonymousМеня приводит в легкое изумление доверчивость бизнеса к облакам. а доверие тут не причем , финансовая сторона перетягивает. "Дешево хорошо не бывает" (с) народная мудрость. По-видимому, отмеченное тут отличие умонастроений в РФ от умонастроений "свободного мира" по данному вопросу как-то связано с тем, что бизнес в России... пуганный , много всякого видел в 90-е и нулевые, доверчивые подвывелись . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2018, 13:33 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Dr. SYSфинансовая сторона перетягивает. Вывод в cloud это большая экономия -> высвобождаются финансы для роста бизнеса (ну или на худой конец для солидных премий)Во-первых если сравнивать не просто стоимость железа+обслуги vs стоимость аренды куска облака, а учесть доп факторы и риски, то можно прийти к прямо противоположному выводу. Во-вторых если зайти с другой стороны то это вообще можно доказать достаточно строго. Раз Ораклу финансово выгодно подсаживать на облачный сервис вместо продажи железок+ПО+поддержки, то наверное клиенту это менее выгодно, не так ли? Если трезво подумать в долгосрочной перспективе. Ремомендую почитать историческую перспективу по ссылке в моем предыдущем сообщении. Для полноты: облака могут иметь смысл для отдельных проектов, но для для всех кто туда лезет или кого туда тянут. Об этом уже тоже было сказано ранее даже с примером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2018, 13:57 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous По-видимому, отмеченное тут отличие умонастроений в РФ от умонастроений "свободного мира" по данному вопросу как-то связано с тем, что бизнес в России... пуганный , много всякого видел в 90-е и нулевые, доверчивые подвывелись . paypal никогда бы не мог зародиться в РФ , по той же причине ему не доверяли бы (ну и банковские регуляции еще) , тем не менее сервис завоевал всемирную популярность и работает 10 с лишним лет уже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2018, 04:35 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Dr. SYSpaypal никогда бы не мог зародиться в РФ , по той же причине ему не доверяли бы если мне не изменяет мой склероз, webmoney и qiwi зародились именно в этой стране, задолго до того, как тут что-то стало известно о PayPal. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2018, 09:03 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
недо scnaесли мне не изменяет мой склероз, webmoney и qiwi зародились именно в этой стране, задолго до того, как тут что-то стало известно о PayPal.Мне казалось, что значительная часть тех, кто первым начал использовать webmoney, qiwi были те, кто не хотел светить операции большому брату. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2018, 10:18 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
AmKadзначительная часть тех, кто первым начал использовать webmoney, qiwi были те, кто не хотел светить операции большому брату. в до-FATCA'овскую эпоху и пэйпалу было глубо пофиг, кто, сколько, кому и куда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2018, 18:32 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
недо scnaDr. SYSpaypal никогда бы не мог зародиться в РФ , по той же причине ему не доверяли бы если мне не изменяет мой склероз, webmoney и qiwi зародились именно в этой стране, задолго до того, как тут что-то стало известно о PayPal. vkontakte тоже , но как и qiwi идея была не российская, а первые аналоги появились не в РФ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 00:32 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
MaximaXXL Ну если к примеру: Есть 2 таблицы: таб1 (Отдел, Сотрудник) - все сотрудники предприятия таб2 (Сотрудник, Время прихода/ухода) - только те сотрудники которые приходили ну и надо увидеть те отделы где на работу приходили все сотружники. Расскажите мне несведущему, как Вы его реализуете не делая объединение таблиц в одном селекте? И это ОЧЕНЬ простой пример И в чем проблема сделать это на сервере приложений? MaximaXXLВот и получаеться Вы тянете 16+ ГБ данных, вместо 2 строчек. А если сервера БД нахожятся в Маями а сервера приложений в Лондоне ... то лучше написать один правильный запрос чем укатывать сервера приложений ... с криками, добавте памяти Прекрасно все реализуется без никаких криков простыми запросами. 1.Вытащить все ID сотрудников, которые приходили на работу, из второй таблицы в коллекцию (это вообще не гигабайты памяти) 2.Проверить по первой таблице, что все сотрудники из отдела в коллекции сознательных работников. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 08:35 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Polar..... И в чем проблема сделать это на сервере приложений? .... Прекрасно все реализуется без никаких криков простыми запросами. 1.Вытащить все ID сотрудников, которые приходили на работу, из второй таблицы в коллекцию (это вообще не гигабайты памяти) 2.Проверить по первой таблице, что все сотрудники из отдела в коллекции сознательных работников. 1. Проблемма в том что 1 запросом вытаскивается ВСЕ данные из второй таблицы которые Вам нужны (а это не 2 строчки как может быть в финальном правильном селекте). Ну и хорошо если вы работаете с сотнями записей, а не в банках с мировым именем, и это сотрудники, а не проводки которых могут быть миллионы. 2.1 Проверить по первой таблице ... это либо будет запрос сложнее чем select * from table1 where ... (если делать сложным запросом то: Вы получеаете не маленькую коллекцию, грузите ее в память и только для того чтобы отправить ее опять на сервер). 2.2 Вам придеться тащить все данные из первой таблицы себе и делать подобие left join, что приводит к получению второй не маленькой коллекции в памяти и их объединение (что соответственно приводит к работе с 2 большими массивами инмемори, хотя финальный селект может вернуть 2 строчки). ну и как итог: 1.больше времени на пересылку/вытаскивание больших(ненужных) объемов данных - увеличение времени работы процесса 2.отжерание памяти на севере приложений (Вам надо туда поместить 1-2 коллекции) - увеличение памяти для работы приложения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 11:37 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
А можно пояснить судьбу Oracle DBA в следующей конфигурации железа 1. Личный (приватный Cloud), например, на базе https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Appliances 2. Oracle Exadata во внутреннем контуре п. 1 Данный модельный пример, что покажет по изменениям в скиллах и потребностям DBA? Игорь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 12:20 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
конечно ВасяА можно пояснить судьбу Oracle DBA в следующей конфигурации железа 1. Личный (приватный Cloud), например, на базе https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Appliances 2. Oracle Exadata во внутреннем контуре п. 1 Данный модельный пример, что покажет по изменениям в скиллах и потребностям DBA? Игорь. 1) При использовании не сертифицированных (читай не oracle) cloud систем, Вам придется лицезировать все CPU системы. Например был наезд на организайию, которая использовала vmware и развернула все базы на выделенном лицензированном сервере. Oracle потребовал лицензирование всех серверов vSphere, так как любую vm можно было перекинуть на другой сервер. 2) Exadata - обычный сервер базы данных, с некоторой спецификой, обычный DBA там востребован. Но поддержка очень нервно реагирует на изменение конфигурации не предусмотренных в штатной настройкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 12:43 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Vadim Lejnin Exadata - обычный сервер базы данных, с некоторой спецификой Вот тут бы я поспорил :) Оно на первый взгляд , конечно, похоже на правду , но если копнуть чуть глубже - то некоторая специфика выливается в отдельный скилл, причем не только для DBA, но даже для разраба средней руки... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 15:54 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousVadim Lejnin Exadata - обычный сервер базы данных, с некоторой спецификой Вот тут бы я поспорил :) Оно на первый взгляд , конечно, похоже на правду , но если копнуть чуть глубже - то некоторая специфика выливается в отдельный скилл, причем не только для DBA, но даже для разраба средней руки... Это да, молотилка данных... в штатах разлетается как горячие пирожки, типа поставил и забыл но там стоимость oracle и железа - капитализация компании, типа круто поэтому не парятся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 16:34 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Vadim LejninЭто да, молотилка данных.. У этой молотилки есть свой, отдельный кластер багов и несовместимостей с "обычным" сервером. Кроме того, не все подходы к проектированию, разработке и оптимизации, применимые к "обычной" БД, подходят для экзадаты. Вернее, у нее - свои подходы, временами вызывающие удивление до оторопи у "классического" базовода :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 16:45 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousотдельный кластер <skipped> несовместимостей с "обычным" серверомМожно подробнее, с примерами? Про баги и разницу подходов вопросов нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 16:55 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
конечно ВасяА можно пояснить судьбу Oracle DBA в следующей конфигурации железа 1. Личный (приватный Cloud), например, на базе https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Appliances 2. Oracle Exadata во внутреннем контуре п. 1 Данный модельный пример, что покажет по изменениям в скиллах и потребностям DBA? Игорь. exadata(программно АППАРАТНЫЙ комплекс) внутри приватный Cloud на базе IBM_WebSphere_DataPower_SOA_Appliances... Штоа ???.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 17:33 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
kinky catконечно ВасяА можно пояснить судьбу Oracle DBA в следующей конфигурации железа 1. Личный (приватный Cloud), например, на базе https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Appliances 2. Oracle Exadata во внутреннем контуре п. 1 Данный модельный пример, что покажет по изменениям в скиллах и потребностям DBA? Игорь. exadata(программно АППАРАТНЫЙ комплекс) внутри приватный Cloud на базе IBM_WebSphere_DataPower_SOA_Appliances... Штоа ???.. месье знают толк в извращениях ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2018, 20:24 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Проблема из пальца высосана. Процент людей, читающих документацию, слава богу, всегда остаётся примерно одинаковым. А ещё говорят, что скоро не то что Oracle DBA не нужны будут, а даже таксисты не у дел будут! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 01:33 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopandrey_anonymousотдельный кластер <skipped> несовместимостей с "обычным" серверомМожно подробнее, с примерами? Про баги и разницу подходов вопросов нет. Какой оригинальный способ цитировать. Британский, должно быть? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 03:08 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
stdioдаже таксисты не у дел будут! Ну из последних новостей на эту тему у нас- Камаз таки саморулился на ~пустых автоподходах к Крымскому мосту и яндекс-авто, самодоехавшее от Москвы до Казани на общих основаниях, в том числе в СМУ. Что там у американцев, японцев и китайцев - даже не знаю, должно быть космические корабли бороздят Большой театр :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 03:14 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Vadim Lejnin1) При использовании не сертифицированных (читай не oracle) cloud систем, Вам придется лицезировать все CPU системы. Например был наезд на организайию, которая использовала vmware и развернула все базы на выделенном лицензированном сервере. Oracle потребовал лицензирование всех серверов vSphere, так как любую vm можно было перекинуть на другой сервер. Нужно было посылать куда подальше. Необходимо лицензировать те сокеты, на которых оракл _выполняется_ или _выполнялся_, а не все доступные в теории. Бремя доказательства нарушения условий лицензирования лежит на истце, задача ответчика - предоставить свидетельства, что оракл выполнялся только на пролицензированных сокетах. Классический развод, прямо по варбуку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 14:51 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Ну, мне впаривали нечно похожее Лицензирование блейдов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 14:58 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Scott TigerVadim Lejnin1) При использовании не сертифицированных (читай не oracle) cloud систем, Вам придется лицезировать все CPU системы. Например был наезд на организайию, которая использовала vmware и развернула все базы на выделенном лицензированном сервере. Oracle потребовал лицензирование всех серверов vSphere, так как любую vm можно было перекинуть на другой сервер. Нужно было посылать куда подальше. Необходимо лицензировать те сокеты, на которых оракл _выполняется_ или _выполнялся_, а не все доступные в теории. Бремя доказательства нарушения условий лицензирования лежит на истце, задача ответчика - предоставить свидетельства, что оракл выполнялся только на пролицензированных сокетах. Классический развод, прямо по варбуку.А если откроют логи vSphere и докажут? Насколько я понимаю, в vSphere это абсолютно нормальная ситуация, что виртуалки ездят на менее загруженные хосты без участия админа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 15:11 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Scott TigerVadim Lejnin1) При использовании не сертифицированных (читай не oracle) cloud систем, Вам придется лицезировать все CPU системы. Например был наезд на организайию, которая использовала vmware и развернула все базы на выделенном лицензированном сервере. Oracle потребовал лицензирование всех серверов vSphere, так как любую vm можно было перекинуть на другой сервер. Нужно было посылать куда подальше. Необходимо лицензировать те сокеты, на которых оракл _выполняется_ или _выполнялся_, а не все доступные в теории. Бремя доказательства нарушения условий лицензирования лежит на истце, задача ответчика - предоставить свидетельства, что оракл выполнялся только на пролицензированных сокетах. Классический развод, прямо по варбуку. Ви таки будете смиятся, но они выиграли суд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 15:44 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Alexander RyndinScott Tigerпропущено... Нужно было посылать куда подальше. Необходимо лицензировать те сокеты, на которых оракл _выполняется_ или _выполнялся_, а не все доступные в теории. Бремя доказательства нарушения условий лицензирования лежит на истце, задача ответчика - предоставить свидетельства, что оракл выполнялся только на пролицензированных сокетах. Классический развод, прямо по варбуку.А если откроют логи vSphere и докажут? Насколько я понимаю, в vSphere это абсолютно нормальная ситуация, что виртуалки ездят на менее загруженные хосты без участия админа. Даже если количество используемых ядер сохраняется? Речь, разумеется, не идет о том чтобы как-то обмануть поставщика ПО. Просто в схожей ситуации, при использовании виртуализации под POWER, при сохранении максимального количества ядер (допустим, динамически убираем/добавляем ядра из LPAR-ов, но суммарное количество ядер во всех LPAR-ах с Oracle не превышает заранее оговоренное и пролицензированное) Oracle Corp считает что все Ок и соглашение не нарушается. Или я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 16:03 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
witteAlexander Ryndinпропущено... А если откроют логи vSphere и докажут? Насколько я понимаю, в vSphere это абсолютно нормальная ситуация, что виртуалки ездят на менее загруженные хосты без участия админа. Даже если количество используемых ядер сохраняется? Речь, разумеется, не идет о том чтобы как-то обмануть поставщика ПО. Просто в схожей ситуации, при использовании виртуализации под POWER, при сохранении максимального количества ядер (допустим, динамически убираем/добавляем ядра из LPAR-ов, но суммарное количество ядер во всех LPAR-ах с Oracle не превышает заранее оговоренное и пролицензированное) Oracle Corp считает что все Ок и соглашение не нарушается. Или я не прав? vmware не является лицензированной платформой для Oracle product, а вот LPAR является ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 16:16 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Vadim Lejninwitteпропущено... Даже если количество используемых ядер сохраняется? Речь, разумеется, не идет о том чтобы как-то обмануть поставщика ПО. Просто в схожей ситуации, при использовании виртуализации под POWER, при сохранении максимального количества ядер (допустим, динамически убираем/добавляем ядра из LPAR-ов, но суммарное количество ядер во всех LPAR-ах с Oracle не превышает заранее оговоренное и пролицензированное) Oracle Corp считает что все Ок и соглашение не нарушается. Или я не прав? vmware не является лицензированной платформой для Oracle product, а вот LPAR является Т.е. вопрос только в лицензированности платформы? Ок, спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 16:20 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
witteVadim Lejninпропущено... vmware не является лицензированной платформой для Oracle product, а вот LPAR является Т.е. вопрос только в лицензированности платформы? Ок, спасибо. LPAR типа является hard partitioning Oracle Partitioning Policy: Server/Hardware Partitioning ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 16:24 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Vadim Lejnin, Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 16:51 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
witteТ.е. вопрос только в лицензированности платформы? Ок, спасибо. Вопрос в том, что Oracle продвигает свою VBox и потому пытается дискриминировать vmWare - ну не любит Ларри конкуренции, что тут поделаешь... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 17:19 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymouswitteТ.е. вопрос только в лицензированности платформы? Ок, спасибо. Вопрос в том, что Oracle продвигает свою VBox и потому пытается дискриминировать vmWare - ну не любит Ларри конкуренции, что тут поделаешь... :) что-что он продвигает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 17:37 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
witteAlexander Ryndinпропущено... А если откроют логи vSphere и докажут? Насколько я понимаю, в vSphere это абсолютно нормальная ситуация, что виртуалки ездят на менее загруженные хосты без участия админа. Даже если количество используемых ядер сохраняется? Речь, разумеется, не идет о том чтобы как-то обмануть поставщика ПО. Просто в схожей ситуации, при использовании виртуализации под POWER, при сохранении максимального количества ядер (допустим, динамически убираем/добавляем ядра из LPAR-ов, но суммарное количество ядер во всех LPAR-ах с Oracle не превышает заранее оговоренное и пролицензированное) Oracle Corp считает что все Ок и соглашение не нарушается. Или я не прав?Вы добавляете/убираете ядра в рамках одной железки. Мне кажется, так можно. Но в приведенном случае решь шла о том, что виртуалка может ездить между (условно) 100 серверами. И да, правильно сказали, что LPAR это hard partitioning http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 17:43 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymouswitteТ.е. вопрос только в лицензированности платформы? Ок, спасибо. Вопрос в том, что Oracle продвигает свою VBox и потому пытается дискриминировать vmWare - ну не любит Ларри конкуренции, что тут поделаешь... :)Нее... Vbox не причина. Она также не признается как средство ограничения количества ядер. Oracle VM - да, но не VBox. И там есть причины: Oracle VM позволяет жестко ограничить ядра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 17:47 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Alexander Ryndinwitteпропущено... Даже если количество используемых ядер сохраняется? Речь, разумеется, не идет о том чтобы как-то обмануть поставщика ПО. Просто в схожей ситуации, при использовании виртуализации под POWER, при сохранении максимального количества ядер (допустим, динамически убираем/добавляем ядра из LPAR-ов, но суммарное количество ядер во всех LPAR-ах с Oracle не превышает заранее оговоренное и пролицензированное) Oracle Corp считает что все Ок и соглашение не нарушается. Или я не прав?Вы добавляете/убираете ядра в рамках одной железки. Мне кажется, так можно. Но в приведенном случае решь шла о том, что виртуалка может ездить между (условно) 100 серверами. И да, правильно сказали, что LPAR это hard partitioning http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf А в чем принципиальная разница если я захочу на другую железяку LPAR-ом уехать, при этом контролируя сколько ядер у меня на целевом LPAR-е будут? Вот в том же документе, приведенном выше, говорится, что в случае POWER и Live Partition Mobility (это как раз потенциальный переезд между физическими ящиками) нужно лицензировать общее количество ядер и на источнике и на приемнике. Да, согласен, некоторое время Oracle как бы работает и там и там (с оговорками, ибо фактически обращение пользователей идут только к одному LPAR-у), но любой администратор в здравом уме постарается минимизировать время переезда, т.е. нет задачи обмануть поставщика ПО, просто миграция, например, да и пользователи никакого профита от этого не получают. Про "есть правила и их нужно соблюдать" мне понятно. Я логику в данном конкретном случае не совсем улавливаю. Ведь в том же случае IBM HACMP у меня плечи чаще всего между разными физическими серверами ездят и ничего, лицензируется только активное плечо. Вот еще пример: я могу настроить добавление/удаление ядер в LPAR-ах на разных физических серверах (при этом LPAR-ы не ездят между физическими серверами), но так чтобы одновременно количество активных ядер не превышало заранее пролицензированное. В этом случае нарушается соглашение с Oracle Corp? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 19:43 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Alexander Ryndin Oracle VM - да, но не VBox. И там есть причины: Oracle VM позволяет жестко ограничить ядра. Сорри, имел ввиду Oracle VM - зарапортовался :) vmWare тоже позволяет ограничивать количество ядер, но Oracle это в расчет не принимает. Так что причина, как мне представляется, в желании продвинуть свой продукт и потеснить конкурента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 19:51 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Alexander RyndinScott Tigerпропущено... Нужно было посылать куда подальше. Необходимо лицензировать те сокеты, на которых оракл _выполняется_ или _выполнялся_, а не все доступные в теории. Бремя доказательства нарушения условий лицензирования лежит на истце, задача ответчика - предоставить свидетельства, что оракл выполнялся только на пролицензированных сокетах. Классический развод, прямо по варбуку.А если откроют логи vSphere и докажут? Насколько я понимаю, в vSphere это абсолютно нормальная ситуация, что виртуалки ездят на менее загруженные хосты без участия админа. Если докажут - то будут правы. Собственно, ответчик должен показать, что такого не было (vmware.log ВМ за спорный период вполне достаточно). Админ может настроить DRS-правила, которые исключат переезд виртуалок, но эти DRS-правила никак не могут являться доказательствами того, что код не выполнялся на других (нелицензированных) CPU. А вот результат работы DRS-правил (подтвержденная работа ВМ с ораклом только на одном или нескольких избранных хостов) - может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 20:20 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Vadim LejninScott Tigerпропущено... Нужно было посылать куда подальше. Необходимо лицензировать те сокеты, на которых оракл _выполняется_ или _выполнялся_, а не все доступные в теории. Бремя доказательства нарушения условий лицензирования лежит на истце, задача ответчика - предоставить свидетельства, что оракл выполнялся только на пролицензированных сокетах. Классический развод, прямо по варбуку. Ви таки будете смиятся, но они выиграли суд Это где и когда? Можно ознакомиться с решением суда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2018, 20:21 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Scott TigerVadim Lejninпропущено... Ви таки будете смиятся, но они выиграли суд Это где и когда? Можно ознакомиться с решением суда? Видимо я поторопился и не до конца разобрался: когда oracle кинул иск против mars, mars отказался пустить их на сервера, где не развернут oracle, тот потребовал прекращение лицензии в сети была паника. Щас полез проверить, а там интересно :) поиск по словам: court of Oracle win vs VMware “programs are available for use” суд до сих пор идет, и судя по всему mars выигрывает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2018, 19:08 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Я так понимаю, что дело закрыто по мировому соглашению, причём в суд подавал как раз Mars. Поправьте, если неправ - в юридическом английском не силён. https://www.fulmerware.com/blog/vmware-virtualization-and-the-oracle-audit-what-every-oracle-customer-needs-to-know-about-the-installed-andor-running-language-of-the-processor-definition и http://houseofbrick.com/mars-vs-oracle/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2018, 00:07 |
|
||
|
|
start [/forum/topic.php?all=1&fid=52&tid=1883723]: |
0ms |
get settings: |
4ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
128ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
77ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 463ms |
| 0 / 0 |
