ASCRUS
Не переживай, пока откаты и админы есть, Оракл не пропадет ;)

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

Оракл просто имеет тучу средств, которыми может воспользоваться админ, чтобы делать еще лучше, надежннее, и (или) вырулить в случае чего. У каких-то СУБД таких средств маловато. Вот и говорят, что адинство не нужно, вместо того, что оно собсно малоэффективно там. А юзера просто не знают, что иначе нельзя. Они ведь и на счетах когда-то считали. Там тоже админства нет.

ASCRUS
Есть сервера, которые тоже имеют тучу средств, чтобы сделать лучше, надежнее и вырулить в случае чего - только без человеческого фактора.

И конечно у них нет багов? Иначе не вырулит без человеческого фактора, потому-что баг может быть у самой выруливалки и не туда зарулит. Поскольку наиболее коварные баги проявляются только при стечении обстоятельств, то про них могли не знать. Иначе зачем в самолетах летчики? Ведь там есть автопилот.
Да и самих событий в БД может быть много - их контроль может потребовать много ресурсов. (Закон сохранения материи).

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

И не без основания, потому что в общем случае это задача ИИ, а термин ИИ означет, что плохо поддается хорошим (в смысле сложности) алгоритмам. И потому ЕИ, т.е. "человеческий фактор" не так уж и глупо.

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

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

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

Вы всерьез думаете, что у Оракла нет внушительного списка конртолируемых событий в БД и возможности настраивать задания, на выполнение либо предусмотренных операций, либо пользовательских ХП? Да и кого их нет из лидирующих СУБД? На это расчитывать врядли стоит.
У него есть тулса Интерпрайз Менеджер, у которого приличный список и более того, расчитано на работу со многими БД одновременно. Но это не бесплатно по ресурсам (особенно если включить все) и человеческий фактор все равно не будет лишним.
Нельзя гарантировать в реальной системе, например, какого-нибудь серьезного банка, где прекращение работы крайне не желательно без админства.

ASCRUS
Можно конечно нанять администратора, который будет каждый день боротся с багами в оптимизаторе и статистике, а можно просто часто и бесплатно исправлять все то, что нашли пользователи. iAnywhere пошла по второму пути - бесплатные ежемесячные паки устраняют все найденные пользователями ошибки и добавляют заявленную пользователями функциональность,

1) Но ведь система у вас без админа. А баг таков что система заглохла. Бум жать месяц? Тем более, что про каждый день речи нет. Достаточно одного в месяц (а то и значительно реже) , но убедительного бага, требующего админа немедленно.
2) Может пойти по всем путям? Ведь все устраняют баги, а уж про функциональность и говорить нечего в условиях конкуренции.

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

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

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

Я то как раз говорил, что справится в некоторых случаях, скорей всего, только ЕИ, т.е. то что Вы назвали человеческим фактором. Потому что некоторые задачи (например, из-за багов) могут плохо поддаваться алгоритмам во во всех ситуациях. Особенно, если допускать, что имеют право на жизнь непредвиденные ситуации. ЕИ можно пытаться заменить только ИИ, чтобы с "автоматом" было. А чем еще?


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

Т.е. там не обученный персонал? Тогда это все равно админство, только не грамотное. Не боитесь, что это еще хуже может быть в общем случае, чем без админа вообще? После такого парня и сам разработчик порой уже ничего сделать не сможет, када без него может и был еще шанс. И никакие автоматы не помогут.
Я, конечно, под нулевым понимал именно без человеческого фактора (т.е. не нуждается в админстве), иначе в чем была реклама ASA? Что там админство считается проще в плане компетентности (в плане простоты при высокой компетенции Оракл всегда претендовал и Вы признали что у него большой список)? Т.е. нужна меньшая компетентность, чтобы что-то выполнить? Например, с помощью хороших интерфейсов? Так на это до сих пор претендовал Скуль. Т.е. вряд ли считался слабее в этом, чем АСА. А с 10 версии и Оракл на это налегает.


ASCRUS
А мне и не надо думать - как бы приходится работать с Ораклом и я неплохо знаком с визуальными утилитами администрирования Оракла. Это уже что то, но этого мало - вот когда юзер после падения сервера сам сможет воткнув CD поднять себе заново приложение с Ораклом, восстановить резервную копию БД, да чтобы все снова шустро и правильно работало - вот тогда и можно будет говорить о нулевом администрировании на этом сервере.

Если не закладываться на баги, то разработчик может ему настроить резервный сервак и тулсу, котрая этот сервак переведет в режим после разрушения первого сервака. Но кто-то же должен решить, что сервак вышел из строя, а не просто немного поглючил. Или просто мультимастер репликацию настроить. Юзер может типа и не заметить падения первого сервака, продолжить работу как ни в чем не бывало, т.е. и CD не придется вставлять. Тодько для проверки работоспособности среды и гарантий, что с копиями все в норме все равно нужен админ. Иначе резервная копия возьми ди и не восстановись в том числе и на АСА. Спортилась, к примеру, а никто этого не знал. Да и где была эта копия? Кто ее туда положил? Если на том же компе, то он мог ведь типа вообще больше никогда не включиться. Как делалась копия? Где архивные журналы повторного выполения? Иначе восстановит только на момент копирования, а этого не всегда достаточно. Админа, то нет.
Или юзер по ошибке удалил не то, что надо и это в копию попало пока хватились. У Оракла, если принять меры и на этот случай есть варианты. Но конечно с каким-никаким админом.

ASCRUS
А где спрашивается гарантия, что админ СУБД справится со своей задачей, не ошибется, быстро проведет восстановление резервной копии и накаты на них уцелевших логов, сможет правильно определить нагрузки и указать оптимальные настройки, и т.д. и т.п. ? Или админы у нас все такие безгрешные и никогда не ошибаются ? И где гарантия что при увольнении опытного админа клиент не попадет с поиском другого грамотного админа ? На моей памяти это случалось гораздо чаще, чем ошибки автоматов в системах с нулевым администрированием.

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

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

Представить то сможет - полно таких. Заказчики не в курсах, что такое админ, и системы по долгу крутятся без админства. Скептическое отношение изменить до конца не сможет, если речь не идет о БД студенческой куросовой.
Так можно однажды и доиграться - закачик будет винить разработчика в случае чего. Зачем это надо? (А так в худьшем случае админ на себя возьмет часить вины - шутка, с долей правды). Одного из 10 внедренных достаточно, чтобы не отмыться потом. Мы чтобы до них дошло, намерено в доке про админа написали.

ASCRUS
Ну да ладно - года через 3, как Оракл доведет до ума свою концепцию нулевого администрирования, тогда и поговорим что такое нулевое администрирование и зачем оно нужно

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

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

Не сисадмина, а админа БД. И не разрушающим багом, а багом, например, который не позволит Вашему автомату восстановить автоматически. Или сделать копию, по которой можно восстановить.

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

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


ASCRUS
В третьих я не могу понять - то ли в Оракле баги плавающие, то ли на клиентов ставятся паки и на них же тестируются, раз ораклисты утверждают, что баг может появиться "вдруг".

Баги могут проявляться при возникновенее определенных условий. Причем в более старших версий, тех которых не былы в более ранних. Например, в 9 Оракле подтип поля FLOAT приводит к тому, что объект нельзя включить в мультимастер репликацию. На 8 этого не было. Он просто не может "понять", что табла содержащая на обоих сайтах этот тип одна и та же. Другой баг - FULL JOIN на первых релизах 9 - при определенном синтаксисе выполняется. Добавил ORDER BY - серверный процесс упал. Т.е. "плавающий". При какой-то сложности синтаксиса наступает баг. Да мало ли. Любая прога обязана содержать ошибки - нас так учили, т.е. надо это учитывать.
Ресурсы "плавающие" - при каком-то их значениии, но не при любом может наступать баг. Разве это только для Оракла характерно?
Вон вспомните авиакатастрофу под Сочи. Там самолет был оснащен капитально. Но собрались в кучу много похих факторов. Такова техника. Ниче не попишешь.

Александр Гoлдун
При крахе сервера в каком-нибудь удаленном филиале можно поднять БД из бэкапа и восстановить работоспособность системы за 30 минут телефонного разговора с не-адвансед юзером.

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

Александр Гoлдун
И очень странное рвение, с которым адепты оракла пытаются доказать, что нет разницы в стоимости обслуживания оракла и, например, SQL Anywhere.
Вообще-то, я думал, что речь идет не о цене, а пренебрежении админством как таковым. Это я считаю слишком беспечным.

Александр Гoлдун
Оракл пока еще монстр, предназначенный в первую очередь как раз для таких задач, причем желательно в сопровождении.

Но во вторую очередь он предназначен не только для таких задач.


Александр Гoлдун
В конце концов, гляньте на любой ресурс с вакансиями на предмет позиции Oracle DBA. Это ни о чем не говорит?

Это может говорить о разном. Но не означет, что присутствуют и задачи где оплата Оракловых админов не так высока. И как я говорил, где и админства то нету. Или есть, но не не-адвансед. И приходится вот так как Вы сказали по телефону или аське и мылу. Но нет уверенности, что не наступит час Х для системы.
Речь о том - хорошо это или плохо. Т.е. может не тока АСА, но сомнительно что это вселяет уверенность.

Рыжий Кот
НИКТО НИКОГДА не признается, но самолету банально не хватило топлива, так как он пошел на дополнительный заход.

Вы уверены? Он ведь собирался обратно по началу. Это важная инфа. Нужно теперь будет спрашивать у стюардес достаточно ли топлива, а то доиграемся.

Рыжий Кот
очень-очень хороший пример, только НЕ В ВАШУ пользу.


Пример, был про стечение в одну кучу нескольких плохих условий. В том смысле как Вы его применили, выглядит будто нулевое администрирование = автоматическое, а не нулевое исключительно ручное. У Оракла тоже полно для автоматизации. Я писал об этом. В частности, автоматическая проверка топлива, не исключает контроля человеческим фактором. А то катастроф может резко возрасти, автомат понавыпускает по сбою полно самолетов без топлива.
Вы еще вспомните Чернобыль. Там парни вмешались. Думаете стоит теперь на всех остальных убрать человеческий фактор? Или пока оставить?
Кстати, если бы на Чернобыле, конструкция корпуса предполагала выброс газа, при достижении оным определенного давления, то был бы всего лишь выброс. Т.е. , например, живучесть может преодолевать человеческий фактор, когда но отрицателен. Но вообще без него, может быть слишком беспечно? Пока ИИ не заменит ЕИ.

Александр Гoлдун
Но оракл пытается и это сделать - залезть не в свой сегмент рынка.

С чего Вы взяли, что не на свой? У него давно были редакции и для маленьких систем.

Александр Гoлдун
Иначе с чего бы это им вдруг пришлось выпустить бесплатную версию? :)
Чтобы не надо было переходить на другие СУБД, для скупого заказчика, когда надо. Думаете интересно с Оракла перескакивать на что-то другое? От добра добра ведь не рекомендуется искать?

FreemanZAV
Скорее чтобы объе,ать скупого заказчика

Вот если бы перешли, то так бы и было скорее всего.