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

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
кроме того в MS SQL вроде как нет триггеров уровня строки ?


В MS SQL триггер срабатывает "на инструкцию" вне зависимости от того, сколько записей ей обработано: 0, 1 или более 1ой. разработчик триггера принимает решение стоит ли использовать курсор в триггере или достаточно реляционного подхода для обработки записей внутри триггера.
24 янв 07, 16:48    [3688965]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Дался Вам этот аудит. :)


Понятно, в Oracle есть AQ
24 янв 07, 16:52    [3688994]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Gluk (Kazan)
кроме того в MS SQL вроде как нет триггеров уровня строки ?


В MS SQL триггер срабатывает "на инструкцию" вне зависимости от того, сколько записей ей обработано: 0, 1 или более 1ой. разработчик триггера принимает решение стоит ли использовать курсор в триггере или достаточно реляционного подхода для обработки записей внутри триггера.


В Oracle есть и триггеры уровня оператора и триггеры уровня строки

По AQ, уведомление может посылаться как в контексте текущей транзакции, так и в контексте автономной транзакции (независимо от результата завершения текущей). Кроме того есть DBMS_ALERT и DBMS_PIPE

Домой пора, завтра хотелось бы вернутся к этой содержательной беседе
24 янв 07, 16:55    [3689028]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
Отложенная проверка, это когда констрейнты проверяются не при выполнении оператора, а при завершении транзакции. Иногда бывает нужно.


Я понимаю...

В MS SQL это делается так:

1. Начинаем транзакцию
2. Отключаем ограничение, которое нам "мешает".
3. Выполняем манипуляцию, которая привела бы к нарушению ограничения.
4. Выполняем манипуляцию, которая приводит все в порядок.
5. Включаем ограничение.
6. Фиксируем транзакцию.
24 янв 07, 17:01    [3689083]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
pkarklin
В MS SQL это делается так:
При многопользовательской работе этот алгоритм может вызвать проблемы, так как должна меняться схема. IMHO, лучше перенести проверку в функцию, а в ней проверять какое-то глобальное условие. Впрочем, это все равно хуже, чем встроенная поддержка механизма отложенной проверки. Причем в ранних версиях MSSQL возможность deffered constraints вроде была, что-то мелькало в документации.
24 янв 07, 17:19    [3689241]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
pkarklin
Gluk (Kazan)
Отложенная проверка, это когда констрейнты проверяются не при выполнении оператора, а при завершении транзакции. Иногда бывает нужно.


Я понимаю...

В MS SQL это делается так:

1. Начинаем транзакцию
2. Отключаем ограничение, которое нам "мешает".
3. Выполняем манипуляцию, которая привела бы к нарушению ограничения.
4. Выполняем манипуляцию, которая приводит все в порядок.
5. Включаем ограничение.
6. Фиксируем транзакцию.

Это не то, в итоге констрейнт не проверится


А вот в Оракле вроде нельзя в триггере уровня оператора менять саму же таблицу, на которой и сработал триггер. А в MS можно

И еще вроде в Оракле DDL не могут быть в транзакции. А в MS можно

Хотя как тут было выше правильно подмечено в оракле это не нужно и даже вредно.
24 янв 07, 17:22    [3689270]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ChA
pkarklin
В MS SQL это делается так:
При многопользовательской работе этот алгоритм может вызвать проблемы, так как должна меняться схема. IMHO, лучше перенести проверку в функцию, а в ней проверять какое-то глобальное условие. Впрочем, это все равно хуже, чем встроенная поддержка механизма отложенной проверки. Причем в ранних версиях MSSQL возможность deffered constraints вроде была, что-то мелькало в документации.


Да, это будет узким местом, ибо будет накладываться Sch-M блокировка, которая не совместима ни с какими другими. Вариант не из лучших. За отложенную проверку Oracle +1.
24 янв 07, 17:25    [3689299]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Yo.!
Guest
pkarklin

Сделали в MS SQL READ COMMITED с поддержкой версионности (который включается опцией бд READ_COMMITTED_SNAPSHOT). Опять не так и не то. Обратите внимание - это касается читателей. Все остальное работает как у обычного блокировочника.

я конечно посмотрю чем это отличается, но не думаю, что это что-то полезное. у МС тут только два варианта, или блокировочные транзакции будут плодить версии как в snapshot или read_commited будет получать неконсистентый набор ... (но это имхо другая опера)

pkarklin

Ну что, теперь "ну фу..." уже не скажешь. Полезем, значит, в детали реализации... Как здесь любят говорит: "Вам шашечки или ехать"?! Хотите использовать версионность - позаботьтесь о размещении tempdb на "шустром устройстве". И методы оптимизации работы с tempdb (особенно на многопроцессорных платформах очень хорошо расписаны в KB).

OK, вот у меня OLTP система - есть 3 диска на двух контролерах, по которым я могу размазать tempdb, как я его должен размазать если понятия не имею как ляжет там карта ? как мне гарантировано развести нагрузку сортировок и версий по разным контролерам ?
24 янв 07, 17:54    [3689521]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
вот у меня OLTP система - есть 3 диска на двух контролерах, по которым я могу размазать tempdb, как я его должен размазать если понятия не имею как ляжет там карта ? как мне гарантировано развести нагрузку сортировок и версий по разным контролерам ?


Если мы хотим добиться от tempdb "достойной производительности", то:

1. Делаем число файлов бд равное числу процессоров (ядер).
2. Кладем (при наличии возможности и это самый "крутой") каждый файл на отдельный диск. Вполне достаточно будет положить файлы данных на массивчик 1+0 (из 4 дисков).
3. Файл лога выносим на отдельный диск (массив).

Разнести нагрузку создаваемую отдельно механизмом поддержки версионности и остальной активностью, для которой нужна tempdb возможности нет. Возможно только увеличить общую производительность при работе с tempdb.
24 янв 07, 18:04    [3689599]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

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

Я понимаю. А поскольку не знаю DTS, то и увидев пакет, вряд ли понял бы.

pkarklin
М.б. использовался Data Driven Query Task, когда для каждой записи из набора выполнялся определенный скрипт.

Вряд ли. Задача была - просто откопировать данные один в один, из исходной таблицы в пустую той же структуры. Поэтому я и держу тот случай в памяти, вроде бы все так просто, что напортачить можно только специально.
24 янв 07, 19:17    [3689972]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
pkarklin
Если под отложенной проверкой понимается отложенная проверка ограничений, то имеется возможность включать\выключать проверку этих ограничений "на лету" в транзакции.

Хм. По моим воспоминаниям, в MSSQL не все типы ограничений могли быть сделаны deferrable - не то foreign keys, не то еще что-то не позволяли. Или я ошибаюсь?
24 янв 07, 19:25    [3689995]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
SergSuper
А вот в Оракле вроде нельзя в триггере уровня оператора менять саму же таблицу, на которой и сработал триггер. А в MS можно

Ошибаетесь. В Oracle нельзя менять таблицу в триггере уровня строки. В MSSQL тоже нельзя - поскольку там такого триггера нет :)

SergSuper
И еще вроде в Оракле DDL не могут быть в транзакции.

Чтобы избежать двусмысленностей, стоит сказать так: в Oracle DDL автоматически сопровождается commit-ом и потому является неоткатываемым. Что до необходимости..... признаться, не ощущаю ни малейшей потребности в "явном коммите DDL" и следующих из этого возможностях, но вполне вероятно, что это следствие привычки к определенному подходу.

В десятой версии появилась весьма правильная возможность с крайне неудачным названием. Суть возможности - выполнение кучи DDL в одной транзакции (и таким образом, откат всех при неудаче). Весьма разумно для задач типа наката патчей. По непонятным мне причинам для этого употребили термин SCHEMA что имхо крайне печально и в будущем непременно приведет к путанице. Впрочем, возможно, это заготовка для того, чтобы отделить понятия SCHEMA и USER, если так, буду очень рад (то, что сейчас в Oracle эти понятия совпадают - с моей точки зрения, весьма неудачно). Так или иначе, пока что это заготовка, которой еще развиваться и развиваться.
24 янв 07, 19:33    [3690026]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer
SergSuper
А вот в Оракле вроде нельзя в триггере уровня оператора менять саму же таблицу, на которой и сработал триггер. А в MS можно

Ошибаетесь. В Oracle нельзя менять таблицу в триггере уровня строки. В MSSQL тоже нельзя - поскольку там такого триггера нет :)

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

А вот заодно еще такой вопрос: может я неправильно понял, но правда ли что в Оракле нельзя делать апдейт связывая таблицы, т.е.:
update a
    set fld=b.fld
  from TableA a, TableB b
  where a.id=b.id
24 янв 07, 22:09    [3690317]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Yo.!
Guest
pkarklin


из статьи
В целях экономии этой памяти mssql вынужден в определеных ситуациях блокировать не на уровне строк (строк с которыми идут операции), а всю таблицу


Ошибочка вышла в определении цели. Цель - производительност. И зависимости производительности от гранулярности блокировок для коротких и длинных транзакций приведен в статье по первой ссылке.

И, самое главное, ее (эскалацию) можно отключить. Как для отдельной таблицы, так и для инстанса в целом. Что дает разработчику\администратору возможность выбора (разумного). Естественно, что в случаи отключения эскалации для таблицы со 100 000 000 записей и удаления всех записей одним делитом надо добавить сиквел серверу памяти. Хотя, вряд ли, кто-то здравомыслящий будет это удалять одним статементом.


вот что пишет msdn:

Additionally, you can disable lock escalation by enabling trace flag 1211. However, this trace flag disables all lock escalation globally in the instance of SQL Server. Lock escalation serves a very useful purpose in SQL Server by maximizing the efficiency of queries that are otherwise slowed down by the overhead of acquiring and releasing several thousands of locks. Lock escalation also helps to minimize the required memory to keep track of locks. The memory that SQL Server can dynamically allocate for lock structures is finite, so if you disable lock escalation and the lock memory grows large enough, attempts to allocate additional locks for any query may fail and the following error occurs

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

на счет размера блоков мне казалось очевидной ...
http://www.ixora.com.au/tips/block_size.htm
http://asktom.oracle.com/pls/asktom/f?p=100:11:3780916029771415::::P11_QUESTION_ID:329017235004
25 янв 07, 00:47    [3690482]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
kennethr
Member

Откуда:
Сообщений: 175
pkarklin
Advanced Scanning

Достаточно было первого абзаца :-). Мне сложно сказать, использует ли Oracle подобные механизмы. Механизм доступа к данным в период выполнения запроса во многом является "черным ящиком", в который можно заглянуть через trace файл. И он эволюционирует гораздо сильнее, чем концепции СУБД. Для разработчика более интересно будет ли FTS или индексный доступ, а не то разделит ли FTS две сессии.
Но возможность такого в MSSQL конечно +.
25 янв 07, 07:35    [3690720]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
pkarklin
Если под отложенной проверкой понимается отложенная проверка ограничений, то имеется возможность включать\выключать проверку этих ограничений "на лету" в транзакции.

Хм. По моим воспоминаниям, в MSSQL не все типы ограничений могли быть сделаны deferrable - не то foreign keys, не то еще что-то не позволяли. Или я ошибаюсь?


Вы не ошибаетесь. Можно отключить FOREIGN KEY и CHECK ограничения.
25 янв 07, 08:12    [3690780]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
SergSuper
А вот в Оракле вроде нельзя в триггере уровня оператора менять саму же таблицу, на которой и сработал триггер. А в MS можно


В триггере уровня строки. Вполне обоснованный запрет. При желании обходится, правда несколько кудряво, но вполне надежно.

SergSuper

И еще вроде в Оракле DDL не могут быть в транзакции. А в MS можно


В Oracle за любым DDL следует неявный commit, обоснования этому также есть, но споры о том как было-бы лучше не утихают. В жизни не особо мешает. Правда это ОДНА ИЗ причин из за которых за DDL в продакт коде отрывают яйца.

SergSuper

Хотя как тут было выше правильно подмечено в оракле это не нужно и даже вредно.


Вредно и противоестественно (для Oracle)
25 янв 07, 08:20    [3690789]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Yo.!
pkarklin

Сделали в MS SQL READ COMMITED с поддержкой версионности (который включается опцией бд READ_COMMITTED_SNAPSHOT). Опять не так и не то. Обратите внимание - это касается читателей. Все остальное работает как у обычного блокировочника.

я конечно посмотрю чем это отличается, но не думаю, что это что-то полезное. у МС тут только два варианта, или блокировочные транзакции будут плодить версии как в snapshot или read_commited будет получать неконсистентый набор ... (но это имхо другая опера)


Мне больше не нравится перспектива, что в одной транзакции могут учавствовать как таблицы с поддержкой версионности так и без оной (если я не ошибаюсь). Мой мозк отказывается сообразить к каким последствиям сие может привести
25 янв 07, 08:23    [3690793]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
SergSuper
А вот заодно еще такой вопрос: может я неправильно понял, но правда ли что в Оракле нельзя делать апдейт связывая таблицы, т.е.:
update a
    set fld=b.fld
  from TableA a, TableB b
  where a.id=b.id


При определенных условиях можно делать update на inline view

update set dst=src
(select a.id id, a.fld dst, b.fld src
 from TableA a, TableB b
 where a.id=b.id)

Если склероз мне не изменил
25 янв 07, 08:31    [3690816]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
kennethr
Но возможность такого в MSSQL конечно +.


Честно говоря не уверен в полезности этой фичи
25 янв 07, 08:33    [3690822]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
kennethr
Но возможность такого в MSSQL конечно +.


В Oracle есть на мой взгля более полезная на мой взгляд фича PQO, Full Scan может быть прозрачно распараллелен.
25 янв 07, 08:34    [3690827]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
SergSuper
pkarklin


В MS SQL это делается так:


Это не то, в итоге констрейнт не проверится


Это управляемый процесс. Сравните:

SET NOCOUNT ON
SET XACT_ABORT ON
GO
CREATE TABLE TestTable(col1 int IDENTITY(1, 1) PRIMARY KEY, col2 int )
GO
ALTER TABLE TestTable ADD CONSTRAINT CK_TestTable_col2 CHECK (col2 > 0)
GO

INSERT TestTable (col2) VALUES(1)
INSERT TestTable (col2) VALUES(2)
INSERT TestTable (col2) VALUES(3)
GO
BEGIN TRAN
  ALTER TABLE TestTable NOCHECK CONSTRAINT CK_TestTable_col2
  INSERT TestTable (col2) VALUES(4)  
  INSERT TestTable (col2) VALUES(-1)
  ALTER TABLE TestTable WITH NOCHECK CHECK CONSTRAINT CK_TestTable_col2
COMMIT


SELECT * FROM TestTable
GO

DELETE TestTable
GO
INSERT TestTable (col2) VALUES(1)
INSERT TestTable (col2) VALUES(2)
INSERT TestTable (col2) VALUES(3)

BEGIN TRAN
  ALTER TABLE TestTable NOCHECK CONSTRAINT CK_TestTable_col2
  INSERT TestTable (col2) VALUES(4)  
  INSERT TestTable (col2) VALUES(-1)
  ALTER TABLE TestTable WITH CHECK CHECK CONSTRAINT CK_TestTable_col2
COMMIT
GO
SELECT * FROM TestTable
GO


DROP Table TestTable
25 янв 07, 08:38    [3690836]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
kennethr
Но возможность такого в MSSQL конечно +.


В Oracle есть на мой взгля более полезная на мой взгляд фича PQO, Full Scan может быть прозрачно распараллелен.


Ну, не надо уж опускать MS SQL так низко. :)

SQL Server provides parallel queries to optimize query execution and index operations for computers having more than one microprocessor (CPU). By allowing SQL Server to perform a query or index operation in parallel by using several operating system threads, SQL Server completes the operation quickly and efficiently.

During query optimization, SQL Server looks for queries or index operations that might benefit from parallel execution. For these queries, SQL Server inserts exchange operators into the query execution plan to prepare the query for parallel execution. An exchange operator is an operator in a query execution plan that provides process management, data redistribution, and flow control. The exchange operator includes the Distribute Streams, Repartition Streams, and Gather Streams logical operators as sub-types, any of which can appear in the showplan output of a query plan for a parallel query. After exchange operators are inserted, the result is a parallel query execution plan. A parallel query execution plan can use more than one thread. A serial execution plan, used by a nonparallel query, uses only a single thread for its execution. The actual number of threads used by a parallel query is determined at query plan execution initialization and is determined by the plan's complexity and the degree of parallelism. Degree of parallelism determines the maximum number of CPUs being used; it does not mean the number of threads being used. The degree of parallelism value is set at the server level and can be modified using the sp_configure system stored procedure. This value can be overridden for individual query or index statements by specifying the MAXDOP query hint or MAXDOP index option.


К сообщению приложен файл. Размер - 0Kb
25 янв 07, 08:48    [3690861]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Ну, не надо уж опускать MS SQL так низко. :)


Рад за MS SQL :)
25 янв 07, 09:01    [3690897]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Gluk (Kazan)
При определенных условиях можно делать update на inline view

update set dst=src
(select a.id id, a.fld dst, b.fld src
 from TableA a, TableB b
 where a.id=b.id)

Если склероз мне не изменил

Как-то не наглядно

А как-нибудь так можно?
update a
   set fld=(select b.fld  TableB b where a.id=b.id)
 from TableA a
 


pkarklin

...
Это управляемый процесс. Сравните:
...

Да это понятно. Но как-то некрасиво выглядит - проверяться будут не действия в транзакции, а всё в таблице. И к тому же получается при в ставке надо иметь права на альтер.
25 янв 07, 09:51    [3691121]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить