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

Откуда: Новоукраинск
Сообщений: 16864
geereye
хм. ну в Киев тоже можно.
Ок, надо будет только как-то связаться.
И, хотелось бы, чтобы хотя бы два человека, а не один, выразили желание :)
Ну, так сказать, на троих сообразить :)
....
"SLA"....
.....


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


мыло в профиле.
2 апр 13, 15:05    [14126851]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
дак фишка в том, что я больше по старостям, а не по новостям.
вот, к примеру, по софту, древний способ первый. генерируется две подсистемы IMS на одной z/OS. А поскольку базы отчуждены от СУБД чуть более, чем полностью, понятие системного каталога отсутствует как класс, то пока одна подсистема обслуживается (ptf накатываются), вторая работает с транзакциями и базами, потом меняются местами.
способ второй - одна машина бьётся на три сущности, coupling facility (меньшая, то есть совсем мелкая), и два LPAR в сисплексе, всё в пределах одной машины, напоминаю. Итого, на две z/OS в двух ЛПАР, допустим, 4 ЦПУ, по 2 ЦПУ в каждом. Останавливаем один ЛПАР с отдачей всей памяти и ЦПУ во второй ЛПАР - он теперь имеет все 4 ЦПУ, и начинаем обслуживать выведенную из эксплуатации ОСь со всеми подсистемами, в то время как общая мощность системы не снизилась - как обслуживалось всё на 4 ЦПУ, так и обслуживается. Потом меняем местами - подымаем обслуженную, выключаем необслуженную. Это, как бы, самая очевидная классика. В зависимости от эксплуатируемых подсистем может быть много чего ещё.
Это так, навскидку, наверняка эксплуатанты ещё способов накидают - сильно будет зависеть, все z/OS разные, каждый сисадмин генерит ОСь под себя, поэтому нету двух похожих ОСей (если только вам не российский офис наклонировал своей багливой нерабочей копии). Потому приёмы и способы будут отличаться в каждом случае.
Ок, письмецо брошу, контакт будет. Тема накатки патчей идёт бок-о-бок с темой восстановления после сбоя, так что можно сразу обе.
2 апр 13, 15:35    [14127032]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
geereye
... по софту, древний способ первый. генерируется две подсистемы IMS ....

Т.е. тема про Оракла против Скуля закончилось тем, что вместо них просто сгенерились подсистемы IMS?
Она же вроде иерархическая. Т.е. как бы, скорее, СУБД первого поколения. А те то что в теме реляционные - второго.
Это все таки может вызывать все еще недоумение.
2 апр 13, 15:46    [14127088]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
geereye
дак фишка в том, что я больше по старостям, а не по новостям.
вот, к примеру, по софту, древний способ первый. генерируется две подсистемы IMS на одной z/OS. А поскольку базы отчуждены от СУБД чуть более, чем полностью, понятие системного каталога отсутствует как класс, то пока одна подсистема обслуживается (ptf накатываются), вторая работает с транзакциями и базами, потом меняются местами.
способ второй - одна машина бьётся на три сущности, coupling facility (меньшая, то есть совсем мелкая), и два LPAR в сисплексе, всё в пределах одной машины, напоминаю. Итого, на две z/OS в двух ЛПАР, допустим, 4 ЦПУ, по 2 ЦПУ в каждом. Останавливаем один ЛПАР с отдачей всей памяти и ЦПУ во второй ЛПАР - он теперь имеет все 4 ЦПУ, и начинаем обслуживать выведенную из эксплуатации ОСь со всеми подсистемами, в то время как общая мощность системы не снизилась - как обслуживалось всё на 4 ЦПУ, так и обслуживается. Потом меняем местами - подымаем обслуженную, выключаем необслуженную. Это, как бы, самая очевидная классика. В зависимости от эксплуатируемых подсистем может быть много чего ещё.
Это так, навскидку, наверняка эксплуатанты ещё способов накидают - сильно будет зависеть, все z/OS разные, каждый сисадмин генерит ОСь под себя, поэтому нету двух похожих ОСей (если только вам не российский офис наклонировал своей багливой нерабочей копии). Потому приёмы и способы будут отличаться в каждом случае.
Ок, письмецо брошу, контакт будет.


Я знаю что такое эксплуатация процессинга, что такое ЛПАР, не первый год с аиксом дружу,
как бросаться ресурсами, как переключаться на стендбай в оракле.
Даже что такое лив партишин мигрейшин знаю.
Но все это не то, когда нужно переключиться без остановки или накатить патч
на несколько терабайтную БД. Не в текстовых ;t файлах движения и остатки хранятся.
Пусть даже ночью, когда пару тройку, до десятка транзакций в секунду пролетает.

SLA однако.



geereye
Тема накатки патчей идёт бок-о-бок с темой восстановления после сбоя, так что можно сразу обе.

Есть мейтененс , есть дизастер , это разные вещи по процедуре, и по SLA
так же как регламентная остановка атомного реактора и аварийная.
или обычные выполения условий договора и формажорные.
Они даже близко не ходят рядом.
Если дизастер позволяет потерю нескольких ( десятков, сотен, тысяч)транзакций с корректировкой потом в аварийном режиме заката солнца в ручную, то мейнтенес нет.
2 апр 13, 16:09    [14127261]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
ДохтаР - так именно что без остановки обслуживания.
а бок-о-бок - потому что технологии одни используются.
Я тым выше менеджер очередей упоминал - немалая доля на него в этой ситуации ложится.
Когда одна система выводится, то запросы к ней не должны "пропасть" - вот они в нём и не пропадают, пока их другая система не извлечёт. И тут уже сам размер баз на дисках мало рояля играет, в такой ситуации, а вот глубина очередей и их надёжность много.
Так что по регламенту вещи - разные, а технологии используют схожие.
ну это теоритезирование - надо на практике смотреть и замерять - на сколько просело время отклика. И вписывается ли оно в заданный SLA.
Тут только смотреть.
2 апр 13, 16:19    [14127337]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
geereye
ДохтаР - так именно что без остановки обслуживания.
а бок-о-бок - потому что технологии одни используются.
Я тым выше менеджер очередей упоминал - немалая доля на него в этой ситуации ложится.
Когда одна система выводится, то запросы к ней не должны "пропасть" - вот они в нём и не пропадают, пока их другая система не извлечёт. И тут уже сам размер баз на дисках мало рояля играет, в такой ситуации, а вот глубина очередей и их надёжность много.
Так что по регламенту вещи - разные, а технологии используют схожие.
ну это теоритезирование - надо на практике смотреть и замерять - на сколько просело время отклика. И вписывается ли оно в заданный SLA.
Тут только смотреть.


Менеджер очердей в общем то понятен , интересует алгоритм синхронизации
актуальных остатков, счетчиков лимитов и статусов, покупюрное строение банкоматных касет ,
деталей прошедших транзакций итд между системами,
после того как одна из систем поднялась из мейтененса.
2 апр 13, 16:32    [14127437]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
И сам менеджер очередей где работает и как его апгрейдить?
2 апр 13, 16:34    [14127448]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
ну тогда лчше не здесь, с таким перчнем, а то я и так баюс, что табретками закидают, за распространение ересей про умершие платформы :)
только у мну щас не совсем процессинг, а платёжная типа КИВИ, вернее, её финансово-учётная составляющая.
но если есть интерес что поглядеть именно в процессинге, то можно подумать, потому как интересно, а любопытство - двигатель прогресса :)
я письмо кинул, может, что и сделаем, чему и научимся.
2 апр 13, 16:36    [14127458]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
geereye
я письмо кинул, может, что и сделаем, чему и научимся.


Ок , я вечером гляну.
2 апр 13, 16:37    [14127464]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
О!
Харроший вапрос!
В нон-стопе он вообще в ОСь встроен.
И есть такой изречени - каждая субд мечтает стать ОСью, но не всем это удалось.
Я к тому, что, к примеру, ИМС это удалось, это фактически ОСь, и менеджер очередей встроен в неё.
вообще транзакционная обработка без менеджера очередей это ересь (ой!). но, наверное, действительно хватит офф-топить :)
пока не применили карательную медицину в виде принудительной психиатрической помощи :)
2 апр 13, 16:40    [14127478]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
geereye
О!
Харроший вапрос!
В нон-стопе он вообще в ОСь встроен.
И есть такой изречени - каждая субд мечтает стать ОСью, но не всем это удалось.
Я к тому, что, к примеру, ИМС это удалось, это фактически ОСь, и менеджер очередей встроен в неё.
вообще транзакционная обработка без менеджера очередей это ересь (ой!). но, наверное, действительно хватит офф-топить :)
пока не применили карательную медицину в виде принудительной психиатрической помощи :)


Транзакционная обработка нормально.
А теория массового обслуживания без манеджера очередей буксует.
:)
2 апр 13, 16:43    [14127489]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
я продолжаю настаивать и будут доказывать (но не тут :) )
достижение нормальных (не здесь) SLA просто невероятно затрудняется без очередей, и становишся как без рук, нормально не спроектировать, не задизайнить!
2 апр 13, 16:49    [14127516]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Yo.!
Guest
geereye
х
И если что где упадёт (что мы знаем никогда не может быть) то вся Москва пол рабочего дня без банкоматов Сбербанка раз в квартал примерно, но это, как нам пояснили, не системная ошибка, это просто случайность, а так все булочки свежие сервера надёжные, ПО отличное!

мда, не умеет оракл ПО делать, даже упасть толком не может. вот мейнфрейм, вот это сила, лежит минимум неделю:
Danske Bank
Flaws in IBM's DB2 database software were responsible for a chain of glitches that turned a routine hardware repair into a weeklong operational crisis, Danske Bank said Thursday in a report on an outage it suffered in March.

http://www.infoworld.com/d/data-management/errors-in-db2-cause-outage-danske-bank-132

думаете кого-то в IBM наказали за недельный простой не самого маленького европейского банка ?
2 апр 13, 20:29    [14128361]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
Yo.! - ма-ла-дец, дец, как мало, смог нагуглить единственный известный случай.
Про оракл сам проблемы найдшь?
можешь не искать, вопрос риторический.
лучше скажи - а что ты знаешь за тот конкретный случай?
Я специально копал, находил людей, которые могли бы пояснить по факту, писал им письма. Потому как не всё известно из печати. Истина покрыта тайной мрака :)
Ну ок был в истории один сбой. По вине бага в ДБ2 (реляционка без багов???? ФАНТАСТИКА! :) )
И?
Оракл уже никогда к этому показателю не приблизится :)
Ладно, это всё фаллометрия, не по делу.
По делу что спросить хочешь?
Только не по ДБ2.
2 апр 13, 21:50    [14128508]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
Главное там в статье - no data was lost
Про вопрос Ларри помним? Ну, просили ли назад клиенты деньги :)
2 апр 13, 21:52    [14128509]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Yo.!
Guest
geereye
Yo.! - ма-ла-дец, дец, как мало, смог нагуглить единственный известный случай.
Про оракл сам проблемы найдшь?

что бы банк неделю из-за оракла лежал не нашел. поможешь ?

geereye
лучше скажи - а что ты знаешь за тот конкретный случай?
Я специально копал, находил людей, которые могли бы пояснить по факту, писал им письма. Потому как не всё известно из печати. Истина покрыта тайной мрака :)

издеваешься ? это "темная" история была освещена на десятке страниц отчета опубликованном банком. в отчете практически по минутам было расписано в какой последовательности рассыпался тот МФ. сначала проглючила железячка, кажется это был диск, диск отключили и решили заменить. после замены обнаружили кашу в данных db2 и в первые сутки наткнулись на три бага в db2.
2 апр 13, 22:25    [14128569]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
нет, не помогу.

по минутам, говоришь? так вот ты неправильную версию расписал.
еще раз - что спрашивать будешь не про дб2?
я сам несколько багов в ней зарегистрировал, так что не лечи меня. Не знеешь, что там было, ищи, раз отчётов валом, только мне этот случай в нос не суй, тем более в твоём неверном изложении :)
могу рассказать, как в регионе РФ базу с бумаг восстанавливали. Думаю, долго. Оракл :)
Так шта - давай не надо, есть что спросить, спрашивай, а на троллинг я не поведусь - годами без sql.ru жил, и ещё годами проживу :)
2 апр 13, 22:30    [14128576]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Yo.!
Guest
geereye,

очень темная история глазами банка
http://www.danskebank.com/link/ITreport20030403uk/$file/ITreport20030403uk.pdf" target="_blank">http://web.archive.org/web/20040914225728/http://www.danskebank.com/link/ITreport20030403uk/$file/ITreport20030403uk.pdf
2 апр 13, 22:48    [14128603]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
как раз оттуда
Guest
Гирай
так я и говорю - у нас своя тусовка, у них своя, перетекание информации крайне затруднено, в определённых областях.
про то, как пивной ларёк автоматизировали, каждый может узнать. Ну, там, сбербанк, к примеру.
а выцепить подробности про Credit Susse, допустим, или Банк Америки, уже куда как тяжелее. А там умудряются опер день в милисекунды закрывать. И спрашивают русских - а вы на чём транзакции проводите? И смеются, услышав ответ, отвечают you are kidding us!
Не верят, буржуи, что мы сплошь на продвинутом софте, что мы их на века обогнали в этом плане :) Как же они бедные без споров то про версионность :)


Вы видимо вендор?? Заметно что вы совершенно не представляете о чем говорите.

Мейнфреймы очень геморойная вещь. Все более менее новые вещи на оракл/ява в основном делаются - платформа гибче и в случае роста или его отсутствия легче переползти на другой сервер или урезать ресурсы, програмистов найти легче чем на фреймы и т.п.
А насчет закрытия опердня в милисекунды у каждого регулятора свои требования и понятия закрытия дня в некоторых регионах/системах просто нет.
Буржуев в основном шокирует диасофт. Они не понимают почему российские банки покупать ЭТО (медленное и унылое г).
Насколько я знаю на западе все по завязанное на производительность -oracle и db2. То что на сиквеле какаянить отчетность и прочее не критикал по. ну и то что сделали когдато на сиквеле как не критикал а потом оно подросло.
Почему? В основном из за инфраструктурных трудностей - под сиквел нужна определенная платформа.
3 апр 13, 11:14    [14129916]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
мне кажется, вы в плену мифов.
гибкость не завист от платформы. Гибкость зависит от положенных в основу принципов, от выработанных на их основе архитектурных решениях, на проектировании, на документировании, на правильно выстроенных процессах обеспечения жизненного цикла.
есть замечательный пример российской разработки, приложение на WAS + DB2, когда явная ошибка в SQL запросе не могла быть увтранена очень долго - пришлось очень много переделывать.
Хотя на той же IMS есть масса примеров, когда из-за большой гранулярности изменения проводятся относительно просто, наксолько это вообще возможно в производстве.

Понятно, что по количеству инсталляций ИМС не может сравниваться с системами на винде или юниксах - это же очевидно.
Отсюда глубокомысленное - ВСЕ новые системы.
Нет, не все. Когда появляются новые крупные финансовые институты, для построения ядра их системы применяется ИМС. А на моей памяти, за последних лет 15, таких института появилось 3, в двух странах.
Так что, насколько я знаю, на западе всё, завязанное на SLA, в том числе ( в том числе только, наряду с прочими) и на производительность, делаются не без участия IMS. Бывает, что и без неё.
3 апр 13, 11:36    [14130028]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Yo.!
Guest
geereye
Нет, не все. Когда появляются новые крупные финансовые институты, для построения ядра их системы применяется ИМС. А на моей памяти, за последних лет 15, таких института появилось 3, в двух странах.

финансовые интситуты северной америки и европы появились в 18 веке, речь о двух странах африки ? кто-то им подарил списанный МФ ?
3 апр 13, 11:43    [14130076]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
geereye
Так что, насколько я знаю, на западе всё, завязанное на SLA, в том числе ( в том числе только, наряду с прочими) и на производительность, делаются не без участия IMS. Бывает, что и без неё.
Все так хорошо начиналось, а оказалось простой рекламной шелухой.
Априори можно сказать, что любое заявление в стиле "только на этом продукте можно делать это" гарантировано является простым рекламным роликом, который никогда и ничем подтвержден быть не может.
3 апр 13, 11:46    [14130099]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
geereye
на проектировании, на документировании, на правильно выстроенных процессах обеспечения жизненного цикла.


современный бизнес развивается насколько быстро , а деньги стоят насколько дешево,
что у бизнесменов и аналитиков нет возможности , что то долго проектировать планировать
Выбрать такой путь - проиграть в конкурентной борьбе с мейнстримовыми технологиями.
3 апр 13, 11:49    [14130117]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
хм.
ну, как бы, ожидаемо.
рекламная шумиха.
как буд-то я вот там выше вот не писал, что можно посмотреть на сделанную систему, покритиковать, попробовать сделать лучше.
можно будет, как закончим.
или нафиг читать то, что не хочется...
ну, кто спросил на посмотреть, я им письма написал, захотят посмотрят, удалённо или в живую, "ни вапрос".
да, с рекламой надо завязывать, и правду.
Сорри, гайз, не смею больше докучать :) Думать, оно всегда трудно, читаем Джека Лондона, белое безмолвие, кажется :)

Йо - китай и объеденённая европа. ты спросил - я ответил.
3 апр 13, 12:05    [14130228]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
как раз оттуда
Guest
geereye
мне кажется, вы в плену мифов.
гибкость не завист от платформы. Гибкость зависит от положенных в основу принципов, от выработанных на их основе архитектурных решениях, на проектировании, на документировании, на правильно выстроенных процессах обеспечения жизненного цикла.
есть замечательный пример российской разработки, приложение на WAS + DB2, когда явная ошибка в SQL запросе не могла быть увтранена очень долго - пришлось очень много переделывать.
Хотя на той же IMS есть масса примеров, когда из-за большой гранулярности изменения проводятся относительно просто, наксолько это вообще возможно в производстве.

Понятно, что по количеству инсталляций ИМС не может сравниваться с системами на винде или юниксах - это же очевидно.
Отсюда глубокомысленное - ВСЕ новые системы.
Нет, не все. Когда появляются новые крупные финансовые институты, для построения ядра их системы применяется ИМС. А на моей памяти, за последних лет 15, таких института появилось 3, в двух странах.
Так что, насколько я знаю, на западе всё, завязанное на SLA, в том числе ( в том числе только, наряду с прочими) и на производительность, делаются не без участия IMS. Бывает, что и без неё.


Под гибкостью тут понимается немного другое. Мейнфрейм это такая штука ПО под которую по достаточно специфично а стоит она дорого и вслучае чего применить ее вычислительные мощьности под что то другое бывает сложно. Поэтому для того чтобы выбить деньги на такую инсталяцию нужны железобетонные основания. А в нашем зыбком мире запустили бизнес пошло пошло- не пошло. Что делать с железкой? Отдать мощьности под другой бизнес или под DR и т.п.
Пошло пошло а потом бешено поперло. Что делать с железкой? купить новую а может просто перехать на что то помощьнее. Куда девать старую? См выше.
А с мейнфреймом такие прыжки превращаются в головную боль из за того что софт специфический. Хорошо если там какойнить db2 стоит и его можно дергать с апп сервера и не знать что где и как крутиться. А если это что то ну очень быстрое но очень специфичное то это может оказаться очень хорошо, а могут оказаться выкинутые деньги.
Просто вы естественно со своей точки зрения вращаясь в мейнфреймах видите что их покупают. Но область их применения не так уж широка. Даже монстры фин индустрии не готовы вкладываться в такие вычислительные мощьности направо и налево.
3 апр 13, 12:31    [14130433]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить