Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
 Основные критерии соавнения СУБД  [new]
artgonch
Member

Откуда:
Сообщений: 345
Здравствуйте!
Подскаджите, пожалуйста, каковы основные критерии нужно учесть при выборе СУБД, если известны требования к будущей разработвке на основе этой СУБД (частые выборки данных, достаточно редкие, но пакетные, операции модификации и вставки строк)?
Заранее спасибо.
26 май 06, 13:00    [2709836]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Yo.!!
Guest
1. выяснение соответствия требований к субд (версионник vs блокировочник, навороты SQL, тригеры/процедуры)
2. цена разработки (типа 1 дорогой программер на нормальной субд за неделю сделает то что толпа средних будет мурыжить месяц на субд без сторед процедур)
3. цена соправождения (кто как будет администрировать, нулевое администрирование - развод для лохов)
26 май 06, 13:18    [2709998]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo.!!
3. цена соправождения (кто как будет администрировать, нулевое администрирование - развод для лохов)

Это ты моим клиентам и серверам на ASA скажи, которые годами работают что с БД, что с репликациями до тех пор, пока винты не вылетают, и то через визарды юзера сами все могут восстановить и дальше себе работать. Так что деньги нам платят за сопровождение ПО и его расширение, а лохи как раз разводятся на ПО, к которому в коробочке нужно прилагать штатного админа.
26 май 06, 13:47    [2710203]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Yo.!!
Guest
2ASCRUS

ну развели вы лохов, поздравляю. рано или поздно они за это заплатят, некоторые из них своим бизнесом.
26 май 06, 13:54    [2710261]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32886

Привет, Yo.!!!
Ты пишешь:

Yo.!!
Y> ну развели вы лохов, поздравляю.
Y> рано или поздно они за это заплатят,
Y> некоторые из них своим бизнесом.
Да, дорогой Йоу, лохи всегда платят.
Но почему-то, всегда другим.
Обидно, да?..

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

26 май 06, 14:03    [2710331]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo.!!
2ASCRUS

ну развели вы лохов, поздравляю. рано или поздно они за это заплатят, некоторые из них своим бизнесом.

Не переживай, пока откаты и админы есть, Оракл не пропадет ;)
26 май 06, 14:08    [2710364]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Yo.!!
Guest
Мимопроходящий

Но почему-то, всегда другим.
Обидно, да?..


почему обидно ? я с этих "других" процент имею :)
26 май 06, 14:09    [2710375]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo.!!
Мимопроходящий

Но почему-то, всегда другим.
Обидно, да?..


почему обидно ? я с этих "других" процент имею :)

Ну хоть честно признался
26 май 06, 14:12    [2710396]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
artgonch
Member

Откуда:
Сообщений: 345
Спасибо за первый ответ.
Все осьальные просто флеймят
26 май 06, 18:35    [2711871]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

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

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

Оракл просто имеет тучу средств, которыми может воспользоваться админ, чтобы делать еще лучше, надежннее, и (или) вырулить в случае чего. У каких-то СУБД таких средств маловато. Вот и говорят, что адинство не нужно, вместо того, что оно собсно малоэффективно там. А юзера просто не знают, что иначе нельзя. Они ведь и на счетах когда-то считали. Там тоже админства нет.
27 май 06, 15:14    [2713138]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
vadiminfo
ASCRUS

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

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

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

Есть сервера, которые тоже имеют тучу средств, чтобы сделать лучше, надежнее и вырулить в случае чего - только без человеческого фактора. Так что проблемы решаются те же, а подходы другие. И если у кого то ходе экплуатации должен участвовать человеческий фактор, то это не доказательство того, что не возможно организовать надежную работу без технического персонала. Другое дело, что те, кто не сталкивался с системами нулевого администрирования, скептически относятся к ним только по той простой причине, что имеют смутные представления, что это такое и чисто психологически проводят ассоциации с ручным администрированием, представляя себе этакий ИИ-код, реализующий этакого умного админа, запрограммированный выполнять те же действия и принимать оптимальные решения, что производит администратор сервера. На самом деле принципы нулевого администрирования не имеет ничего общего с данными представлениями, однако по идее это отдельная тема, где много и подробно нужно обсуждать такие понятия, как автоматы, проектирование моделей поведения, функциональность обеспечения надежности и защиты, интерфейс конечного пользователя управления сервером, удаленное управление через оффлайн и прочие многие вещи, коих в примеру в ASA целый огромный список. Так что если к примеру, у Оракла внушительный список настроек, позволяющих администратору проводить тонкую настройку системы в зависимости от условий эксплуатации, то у ASA не менее внушительный список автоматом, механизмов и функциональности, позволяющих на этапе разработки проектировщику БД закладывать поведение сервера на различные условия эксплуатации, где каждый автомат обладает четким кругом решения задач и проектировщик учитывает, пользуется и управляет ими, обвязывая своей бизнес-логикой на уровне языка хранимых процедур.
27 май 06, 19:17    [2713419]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

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

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

ASCRUS

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

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

ASCRUS

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

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

ASCRUS

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

Вы всерьез думаете, что у Оракла нет внушительного списка конртолируемых событий в БД и возможности настраивать задания, на выполнение либо предусмотренных операций, либо пользовательских ХП? Да и кого их нет из лидирующих СУБД? На это расчитывать врядли стоит.
У него есть тулса Интерпрайз Менеджер, у которого приличный список и более того, расчитано на работу со многими БД одновременно. Но это не бесплатно по ресурсам (особенно если включить все) и человеческий фактор все равно не будет лишним.
Нельзя гарантировать в реальной системе, например, какого-нибудь серьезного банка, где прекращение работы крайне не желательно без админства.
27 май 06, 22:40    [2713674]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
vadiminfo
И конечно у них нет багов? Иначе не вырулит без человеческого фактора, потому-что баг может быть у самой выруливалки и не туда зарулит. Поскольку наиболее коварные баги проявляются только при стечении обстоятельств, то про них могли не знать. Иначе зачем в самолетах летчики? Ведь там есть автопилот.

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

vadiminfo

Да и самих событий в БД может быть много - их контроль может потребовать много ресурсов. (Закон сохранения материи).

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

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

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

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

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


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

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

vadiminfo
Нельзя гарантировать в реальной системе, например, какого-нибудь серьезного банка, где прекращение работы крайне не желательно без админства.

А где спрашивается гарантия, что админ СУБД справится со своей задачей, не ошибется, быстро проведет восстановление резервной копии и накаты на них уцелевших логов, сможет правильно определить нагрузки и указать оптимальные настройки, и т.д. и т.п. ? Или админы у нас все такие безгрешные и никогда не ошибаются ? И где гарантия что при увольнении опытного админа клиент не попадет с поиском другого грамотного админа ? На моей памяти это случалось гораздо чаще, чем ошибки автоматов в системах с нулевым администрированием.
28 май 06, 00:55    [2713786]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

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

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

ASCRUS

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

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

ASCRUS

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

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


ASCRUS

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

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


ASCRUS

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

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

ASCRUS

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

Так это только увеличивает значимость роли админа. Т.е. не только без админа плоховато, но имеет значение его квалификация.
28 май 06, 02:03    [2713829]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Yo.!!
Guest
ASCRUS
[ iAnywhere пошла по второму пути - бесплатные ежемесячные паки устраняют все найденные пользователями ошибки

оригинально, патчи каждый месяц, зато администрирование нулевое. предлагаю секретаршу назначить ответственой за патчи, а че нам информация ? это ж это фигня, всего пару баксов стоит, почему бы ее секретарше не доверить ? в крайнем случае другую наймем, а и из бэкапа как нибудь поднимим (идея - бэкап поваренка поднимать научим, че там уметь все равно 2 команды ). какое-то время конечно это займет, но че бизнес не понос - пару дней потерпеть может, если поваренок не в духе, повесим объявление :)

ASCRUS

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

супорт, именно для этого его и придумали. 360*24 часа в сутки супорт. 18% в год от лицензий и бизнес себя чует сухо и местами комфортно.

ASCRUS

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


я не видел виндовс адекватно работающим больше 2х месяцев в одиночестве без патчей, а ты нам рассказываешь про автоматы, причем который раз. а как начинаем разбиратся - так выясняется что в asa ничего лучше mysql не предлагает. я понимаю ведущие субд, они и i/o автоматом балансируют, и ресурсы ограничивают, и sql способны анализировать, практически все ddl налету выполняют. вот именно это помагает админу и asa в этом плане еще нужно будет очень долго рости.
28 май 06, 04:26    [2713848]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67427
Блог
ASCRUS
баги есть везде и самым важным пользователям является как раз вопрос, как быстро они исправляются и сколько это стоит.

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

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

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

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

Хм. Количество событий зависит не столько от задачи и какой-то неведомой бизнес-модели, сколько от самого сервера. И я уверен, что для любого сервера их будет довольно много (достаточно, чтобы тщательный аудит существенно отнимал ресурсы).

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

Прямо сейчас я делаю такую систему. Но за клиентов с существующим администратором мне таки будет спокойнее. В частности потому, что уже добрую неделю наблюдаю беседы своего коллеги с одним из наших клиентов, пытающимся выполнить операцию "скачать setup.exe с сайта и согласно приложенной инструкции нажать несколько кнопок".
28 май 06, 09:55    [2713898]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Ладно - умываю руки. Если человек не может представить себе систему с нулевым администрированием, потому что изначально его система работает в связке с администратором, то значит он никогда не сможет себе ее представить. Ну да ладно - года через 3, как Оракл доведет до ума свою концепцию нулевого администрирования, тогда и поговорим что такое нулевое администрирование и зачем оно нужно

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

Softwarer:
Инсталяция конечно круто, как насчет переноса БД между серверами и восстановлением с архивных копий по всем моделям восстановления - Ваша утилита тоже это сама будет для клиентов на Оракле все обеспечивать ? Если да, то она стоит бешенных денег, можно разбогатеть ;)

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
28 май 06, 11:37    [2713959]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

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

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

ASCRUS

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

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

ASCRUS

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

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

ASCRUS

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

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


ASCRUS

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

Баги могут проявляться при возникновенее определенных условий. Причем в более старших версий, тех которых не былы в более ранних. Например, в 9 Оракле подтип поля FLOAT приводит к тому, что объект нельзя включить в мультимастер репликацию. На 8 этого не было. Он просто не может "понять", что табла содержащая на обоих сайтах этот тип одна и та же. Другой баг - FULL JOIN на первых релизах 9 - при определенном синтаксисе выполняется. Добавил ORDER BY - серверный процесс упал. Т.е. "плавающий". При какой-то сложности синтаксиса наступает баг. Да мало ли. Любая прога обязана содержать ошибки - нас так учили, т.е. надо это учитывать.
Ресурсы "плавающие" - при каком-то их значениии, но не при любом может наступать баг. Разве это только для Оракла характерно?
Вон вспомните авиакатастрофу под Сочи. Там самолет был оснащен капитально. Но собрались в кучу много похих факторов. Такова техника. Ниче не попишешь.
28 май 06, 13:30    [2714079]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Спор у вас какой-то странный. И очень странное рвение, с которым адепты оракла пытаются доказать, что нет разницы в стоимости обслуживания оракла и, например, SQL Anywhere. Да, эта разница постепенно сокращается - в Оракле делают дружественные визарды для домохозяек и т.д., но она есть и все еще достаточно большая. У них просто разная архитектура и разные сегменты рынка, для которых они оптимальны. Архитектура и идеология ASA очень простая - тут и визарды особо не нужны для упрощения понимания и управления этим. При крахе сервера в каком-нибудь удаленном филиале можно поднять БД из бэкапа и восстановить работоспособность системы за 30 минут телефонного разговора с не-адвансед юзером. Или если есть захудалый канал, то вообще самостоятельно поднять на любом компе, залив туда архив 3 мб и запустив батник в несколько строчек. А можно и заранее предусмотреть это - батником в две строчки организовать "живой" бэкап и обеспечить автоматический подъем резервного сервера при падении основного с потерей только последних незакоммиченных транзакций. Но эта простота, как ни странно, не противоречит наличию у сервера весьма богатых функциональных возможностей, отличного оптимизатора, возможности эффективно работать с большими нагрузками и большими объемами данных.

Разумеется, терабайтные базы и десятки тысяч юзеров - стихия монстров, туда я с ASA не сунусь (пока). Но сколько таких задач в процентах от всех прочих? Оракл пока еще монстр, предназначенный в первую очередь как раз для таких задач, причем желательно в сопровождении
vadiminfo
админа, который в ходе эксплуатации знает каждый винтик,

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

softwarer

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

Прямо сейчас я делаю такую систему.

И как успехи (без сарказма)? В поставке ASA даже готовые шаблоны для Install Shield под это есть, хотя сам я предпочитаю, как писал выше, архив 3-5мб и батник 2-3 строчки.
28 май 06, 16:32    [2714326]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
vadiminfo
Вон вспомните авиакатастрофу под Сочи. Там самолет был оснащен капитально. Но собрались в кучу много похих факторов. Такова техника. Ниче не попишешь.


очень-очень хороший пример, только НЕ В ВАШУ пользу.
Говорю со всей ответственностью, так как верчусь в этом винегрете.
НИКТО НИКОГДА не признается, но самолету банально не хватило топлива, так как он пошел на дополнительный заход. В армении очень проблемно с топливом, заправляются впритык. Т.е. АДМИН решил заправить столько, сколько ЕМУ показалось достаточным. Было бы "нулевое администрирование", вылет был бы запрещен.
З.Ы. я не фанат ASA, но она действительно не требует обслуживания
28 май 06, 16:34    [2714330]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Рыжий Кот
vadiminfo
Вон вспомните авиакатастрофу под Сочи. Там самолет был оснащен капитально. Но собрались в кучу много похих факторов. Такова техника. Ниче не попишешь.


очень-очень хороший пример, только НЕ В ВАШУ пользу.
Говорю со всей ответственностью, так как верчусь в этом винегрете.
НИКТО НИКОГДА не признается, но самолету банально не хватило топлива, так как он пошел на дополнительный заход. В армении очень проблемно с топливом, заправляются впритык. Т.е. АДМИН решил заправить столько, сколько ЕМУ показалось достаточным. Было бы "нулевое администрирование", вылет был бы запрещен.
З.Ы. я не фанат ASA, но она действительно не требует обслуживания

напомнило историю про гимли планер
там админ 767-го боинга конечно разрулил ситуацию, и умудрился спланировать 132-тонный самолет... но решение "на глазок" заправлять самолет в отсутствии работающих датчиков топлива - тоже админ принимал :)
28 май 06, 16:44    [2714350]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Yo.!!
Guest
Александр Гoлдун
Спор у вас какой-то странный. И очень странное рвение, с которым адепты оракла пытаются доказать, что нет разницы в стоимости обслуживания оракла и, например, SQL Anywhere.

нет вы не поняли :) совсем не поняли - мы говорим о том, что разница громадна и что ASA выглядит очень блекло в сравнении со взрослыми субд в этом плане. Я например не вижу чем ASA продвинулась дальше foxpro в этом плане, там тоже можно копировать и тоже админ типа не нужен. но безопасность и непрерывность бизнеса не от визардиков зависит, а от технологий. что есть в ASA в плане технологии ? есть балансировка i/o ? есть ли ограничение ресурсов ? возможность автоматически реагирорвать на изменении типа нагрузки (перераспределить память под OLAP с утра и на OLPT в час пик) ? единая консоль для всех субд и апп серверов ? и т.д. и т.п.

Александр Гoлдун

Разумеется, терабайтные базы и десятки тысяч юзеров - стихия монстров, туда я с ASA не сунусь (пока).

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

Александр Гoлдун

Но сколько таких задач в процентах от всех прочих?

где-то 70% рынка, ето если ужасный оракл с суровым db2 (as/400 и мейнфремы) сложить.

ЗЫ. единствено, что ASA извиняет что эти навороты действительно не критичны на том сегменте рынка. похоже у вас бизнес не развалится если в результате нулегого администрирования бэкап оказался битым.
28 май 06, 17:42    [2714421]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Александр Гoлдун

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

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

Александр Гoлдун

И очень странное рвение, с которым адепты оракла пытаются доказать, что нет разницы в стоимости обслуживания оракла и, например, SQL Anywhere.

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

Александр Гoлдун

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


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


Александр Гoлдун

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

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

Рыжий Кот

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

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

Рыжий Кот

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


Пример, был про стечение в одну кучу нескольких плохих условий. В том смысле как Вы его применили, выглядит будто нулевое администрирование = автоматическое, а не нулевое исключительно ручное. У Оракла тоже полно для автоматизации. Я писал об этом. В частности, автоматическая проверка топлива, не исключает контроля человеческим фактором. А то катастроф может резко возрасти, автомат понавыпускает по сбою полно самолетов без топлива.
Вы еще вспомните Чернобыль. Там парни вмешались. Думаете стоит теперь на всех остальных убрать человеческий фактор? Или пока оставить?
Кстати, если бы на Чернобыле, конструкция корпуса предполагала выброс газа, при достижении оным определенного давления, то был бы всего лишь выброс. Т.е. , например, живучесть может преодолевать человеческий фактор, когда но отрицателен. Но вообще без него, может быть слишком беспечно? Пока ИИ не заменит ЕИ.
28 май 06, 18:27    [2714473]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
я немного поофтоплю (я не люблю сервера, sql, код и пр.)
Чернобыль накрылся, потому что персонал начал экспериментировать (админ решил потюнить параметры, которые нигде в мире еще не менялись, причем на очень опасном оборудовании в центре европы)
Про самолет: очень важно слушать всю информацию, потому как ближе к официальной версии начинают заметать следы. Товарисчи СМИ имели неосторожность выпустить в эфир разговор летчика с грузинским диспетчером, где прозвучала инфа о недостаточности топлива. Самолет ныряет просто так вниз по немногим причинам: если он развалился, если резко отказали все двигатели (такое по вероятности равносильно одновременному выходу двух дисков в зеркале), если нет тяги. Зная, что топливо в армении запрявляют впритык, что было высказано беспокойство о его нехватке уже в воздухе, что самолет упал за несколько км до полосы, при этом сделав уже одну попытку захода, я никогда не поверю, что причиной была плохая погода. Проще впарить общественности эту версию, нежели выплачивать компенсации и садиться за решетку.
28 май 06, 18:49    [2714502]     Ответить | Цитировать Сообщить модератору
 Re: Основные критерии соавнения СУБД  [new]
Yo.!!
Guest
2Рыжий Кот
как раз все наоборот - чекнутый человек угроза одному реактору, в то время как ерунда типа сламера может легко шарахнуть сотни реакторов разом. про инциндент на ядерной электростанции в штатах слышал ? там сламер забив канал просто отключил весь мониторинг за реакторами. и именно из-за отсутствия нормального админа который вовремя не позаботился о патче.
а на счет самолетов в это расмешило:
http://www.cnews.ru/news/line/index.shtml?2006/03/20/198008
28 май 06, 19:28    [2714612]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить