(OT???): Oracle vs. MS-SQL

[Ivan Brezina]

Karel Salavec wrote:

> Dne Út, 12 čen 2001 jste napsal(a):
> 
>>On Tue, Jun 12, 2001 at 02:25:52PM +0200, Libor Mitrenga wrote:
>>
>>
>>>No já si myslel, že při jakémkoliv zápisu v rámci transakce do tabulky se 
>>>"celá" tabulka na MS SQL zamkne až do ukončení transakce.
>>>
>> tzv. "velkolepe MySQL transakce"? :-)
>>
>> Oni transakce jsou primarne o moznosti vratit DB do stavu pred BEGIN, 
>>ale pak je tu dalsi vec a to jak se budou chovat konkurujici si operace.
>>
>> Jde to propracovat az tak ze do provedeni COMMITu jsou udrzovany dve 
>>verze dat takze jde cist bez cekani a zamku i data ktera nekdo zrovna 
>>meneni v nejake transakci. Viz. PostgreSQL a jeho Multi-Version 
>>Concurrency Control (MVCC).
>>
> 
> dtto Oracle
> 
> 
>>>To je určitě nevýhoda pro MS SQL server, ale tato vlastnost nemusí "vadit", 
>>>když bude aplikace navržena tak, že deadlock nemůže vzniknout. Nemám 
>>>zkušenosti s Oracle, ale jeho inteligentní zamykání zase může zpomalovat chod 
>>>transakcí, ale nazahltí se server (mohou jet vedle sebe paralelně transakce, 
>>>které zapisují do stejných tabulek). Jinak si myslím, že deadlock může jistě 
>>>vzniknout i na Oracle, když bude špatně udělaná aplikace.
>>>
>> Jak uz tu nekdo psal deadlock udelate snadno, staci pokud se pokusi dve
>>transakce "krizem" o update stejnych radek ('A' udela update dat 'a', 
>>'B' udela update dat 'b', 'A' se pokusi o update dat 'b' a ceka, 
>>'B' se pokusi o update dat 'a' a mete deadlock .. ale rozumna DB ho 
>>detekuje a udela rollback transakce 'B').
>>
>>
>>>Proto velmi záleží na typu aplikace a na datovém návrhu databáze a na 
>>>fukcích, které s těmi daty mají manipulovat. Podle tohoto bych volil DB 
>>>server, který je pro mě lepší. Na telefonní seznam je určitě nejlepší MySQL a 
>>>vůbec mi nevadí, že nemá transakce, ale jen zamykání.
>>>
>> Zamykani na urovni radku vs. zamykani na urovni tabulek (stranek apod.)
>>tezko budete resit v datovem modelu a funkcich. Je to o tom co vam udela
>>vykon DB pri 100 na jednou pracujicich klientech nad stejnymi daty. Proto 
>>napriklad pekelny vykon MySQL jde dost dolu v testech ktere toto testuji. 
>>A s tim, ze klient A i B chce udelat update na stejnou tabulku udela datovy
>>model kulove.... 
>> Pochopitelne, ze tyto zamky na radkach neco stoji, ale celkem brzo se to
>>vyrovna pokud je tam vice konkurujicich si klientu.
>>
> 
> Naprosty souhlas.
> 
> Dovolil bych si jeste pripodotknout - z praxe vim, ze i pri znacne zatezi (cti
> podstatne vyssi, nez je dimeznovane zelezo) Oracle stale jede. Sice pomalu, lae
> jede. Nechci rikat, co v takovem pripade udela M$ SQL (a davat to pak do kupy
> ... :-((( )
> 
> Dalsi, dosud nezohlednene (fuj, to je slovo) hledisko je bezpecnost. Pokud se
> vam nekdo dostane na M$ SQL, ma moznost plne vlady nad strojem (a neda se to
> vypnout!). Oracle vyslovne nuti k tomu, aby db bezela pod neprivilegovanym
> uzivatelem.
Ono to sice tak vypada, ale staci dat unset ORACLE_HOME a spustit dbsnmp,

(to musi bezet bezet pod rootem) ono zmagori, vyhodi log soubor s chybou 
a za chvili je z vas root. Pokud to s bezp. myslite vazne odstrante s-bit
vsech programu s root s-bitem v oracle. (dbsnmp a lsnrtlc).

Mozna uz je to opraveny, ale tahle chyba se tahla s oraclem dost dlouho 
a na buqtraq si stezovali, ze je oracle ignoruje.

Na druhou stranu je pravda, ze tech exploitu(spatnejch def. nastaveni, 
..atd) ma MS daleko vic.

Ivan