rdbms’es are evil
May. 27th, 2009 01:17 pmНовичкам » Первые шаги в ORACLE (цикл из 142 статей)
o_0
UPD: как можно нагуглить много дампов оракла (случайно обнаружил, поковыряв дамп руками)Новичкам » Первые шаги в ORACLE (цикл из 142 статей)
o_0
UPD: как можно нагуглить много дампов оракла (случайно обнаружил, поковыряв дамп руками)
no subject
Date: 2009-05-27 08:53 pm (UTC)no subject
Date: 2009-05-27 08:59 pm (UTC)no subject
Date: 2009-05-28 02:18 pm (UTC)Думай позитивно - станешь Oracle экспертом и у тебя будет куча денег и уважения.
no subject
Date: 2009-05-27 09:15 pm (UTC)no subject
Date: 2009-05-28 08:14 am (UTC)Ну взять хотя бы неблокируемые Select'ы для Oracle непринципиально одна сессия делает выборку, или 1000, причем вперемешку с DML. В MS SQL пойдут блокировки, которые и ограничивают масштабируемость.
Блин, ну как такое можно писать без каких-либо оснований. Хорошо, я напишу - RAC превосходно работает.
Ну и еще раз, смотря для чего использовать. Для бухгалтерского приложения, которое должно масштабироваться на 100-1000 одновременных сессий, или это OLTP c тысячами запросов в секунду?
no subject
Date: 2009-05-28 08:03 pm (UTC)select - это и есть dml.
с чего вы взяли, что я пишу без оснований?
no subject
Date: 2009-05-28 08:19 pm (UTC)Я могу ошибаться, я с MS SQL Не работал уже очень давно.
Неблокируемые SELECT'ы это dirty-read, т.е 2 SELECT'а, запущенные в одно и то же время могут вернуть разные результаты, Oracle возвращает данные, актуальные на момент начала выполнения операции SELECT, не важно были изменения, или нет.
Я имед в виду dml, который модифицирует данные, update / delete.
Да нет, я не думаю, что вы написали без каких-либо оснований, просто само утверждение "не работает" без аргументации смотрится некрасиво
no subject
Date: 2009-05-28 08:25 pm (UTC)это точно. но на этот счёт есть гугол, в котором легко находится, например, это:
http://msdn.microsoft.com/en-us/library/ms345124.aspx
no subject
Date: 2009-05-28 09:31 pm (UTC)Но transaction-versioning дает все-таки overhead на update / delete.
А вообще, да, многое поменялось, надо будет присмотреться к MS SQL как-нибудь.
Обидно, что во всех статьях MS сравнивается SQL Server и Oracle и конечно первый бьет по всем показателям, в документации Oracle тоже самое. В таких документах слишком много маркетингового bullshit'а, который далекий от реальной жизни. Пока рылся, нашел документ http://www.oracle.com/technology/products/database/clustering/pdf/twp_racsqlserver_2008.pdf.
Это тот же документ, ссылку на который вы мне давали SQL Cluster vs RAC, только наоборот. Здесь Oracle поносит решение от MS и восхваляет свое.
По фичам Oracle точно впереди, а вот актуален ли титул "the most scalable rdbms" непонятно - все лгут.
no subject
Date: 2009-05-28 09:57 pm (UTC)точно так же, как у оракла :)
имплементация-то практически такая же.
no subject
Date: 2009-05-28 10:08 pm (UTC)no subject
Date: 2009-05-28 08:18 pm (UTC)http://download.microsoft.com/download/e/8/e/e8ec4b71-bf13-4fd5-9af5-aabcbec859e6/RealityBehind_RAC.pdf
no subject
Date: 2009-05-28 08:33 pm (UTC)По поводу high-availability могу точно сказать - работает, и automatic-failover работает - это то, что я лично проверял. По поводу scalability я ничего сказать не могу - сам не пробовал, Да и я больше оракловую документацию изучаю, а там, как вы понимаете, все солнечно.
Но вообще-то интересно конечно было бы замерить perfomance RAC.
no subject
Date: 2009-05-28 11:30 pm (UTC)тем не менее, вот у меня стоит в продакшене sql server, производящий 30 тысяч транзакций в секунду. 16-way (4х4) + DAS, никаких SAN-ов. стоимость железа - under 40K. если прибавить стоимость лицензий, сколько будет? предположим, 65К. у оракла нет никаких шансов произвести 30К транзакций в секунду на системе общей стоимостью 65К. даже и в три раза меньше транзакций произвести нету шансов.
no subject
Date: 2009-05-29 09:13 am (UTC)Oracle на этом же железе взлетит (кстати, в последнее время на Sun'ах Oracle работает отвратительно), дальше есть лицензия на пользователя, по-моему где-то 2к. Так что на эту же конфигурацию мы можем повесить 10 пользователей. Транзакций / сек, мне кажется в этом случае можно выжать и больше, зависит от того, как базу тюнить.
no subject
Date: 2009-05-29 04:48 am (UTC)