MS SQL и тесты производительности...

для анонима-Оракла
>>>Просто мое заявление, что многоверсионность не позволяет видеть
>>>результаты незакоммиченных транзакций, было осмеяно и >опровергнуто.
Там было несколько не так. Утверждалось что система многоверсионности вводилась для того, чтобы не видеть закоммиченных после запуска запроса транзакций(как следствие более легкий путь для поддержки read only транзакций). Обычный запрет грязного чтения присутствует во всех СУБД. Оракл (Interbase кстати тоже) сделал нечто отличное.
Конечно система многоверисонности не позволяет грязного чтения, было бы глупо для его запрета вводить еще какой-то механизм управления транзакциями. Возможно(или давайте допустим это), что первые версии Оракла вообще не имели системы многоверсионности, а потом ее ввели, - вот и подумайте аноним - ДЛЯ ЧЕГО? - Для того, чтобы не видеть результаты закомиченных после запуска запроса транзакций. - Ежику же понятно. Ну сами подумайте в sybase нет такой системы, а Оракл ее ввел. - Для чего? - Наверное, чтобы иметь какие-то принципиальные отличия, и запрет грязного чтения к ним не относится(хотя конечно, вы правы, эта система запрещает грязное чтение, - но воодилась она не для этого, есть более простые пути для запрета грязного чтения).
Имено для того, чтобы иметь СВОЮ ВЕРСИЮ базы(снимок) для каждого запроса или составной транзакции (или вообще сессии) НА МОМЕНТ ЗАПУСКА, и не использовать при этом блокировки как Sybase/mssql.
Под это определение не попадут и не закоммиченные строки (не было не закоммиченной строки в снимке- не будет ее и в result set'е ).

for Havoc
>Мне всегда казалось, что это рулится уровнями изоляции транзакций >без привязки к тому, что за сервер: версионник или блокировочник.

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

а что такое read commited?
Это не один из уровней изоляции?

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

to anonymous (*) (2001-03-25 19:19:05.0)

>(Так между прочим, про Окуджаву писал я, а где о собаке, то кто-то >другой)
А про стаж на зоне не Вы?
Я это к тому, что не спутали ли Вы поэзию Окуджавы со стряпней Токарева?

>1. На зоне, чем больше отмотал, тем быстрее откинешься
>Я эток тому, что не спутали ли Вы Окуджаву с Токаревым?

[..]

>>Я оно, конечно, сильно извиняюсь, но не надо пытаться выгородить >>себя Вопрос в этой дискуссии никогда не стоял ДЛЯ ЧЕГО ВВОДИЛАСЬ >МНОГОВАРИАНТНОСТЬ (или монговерсионность).
>Вами было заявлено, Что
>1. многверсионность является недостатком
>------------------------
>Просто есть и недостатки (у Оракла), а в некоторых случаях и >достоинтва являются недостатками(монговерсионность и OLTP).
>------------------------
>2. На что я заявил, что она позволяет не видеть результата >незавершенных транзакций

Сударь, Вы не так заявили. Вы сказали:

>А как иначе, Вы бы хотели видеть результат незавершенных транзакций?
>Я бы нет.

Так вот иначе. Как в других СУБД.
Без многоверсионности в sybase/mssql я их не вижу. Про, что вам и талдычат здесь.
Вообще, этот спор похож на занятия по математике Мальвины с буратино.
-Буратино, у тебя два яблока, некто взял у тебя одно. Сколько у тебя
осталось?
-Два. Я не дам некту яблока.
Аноним-оракл, мы отвлеченно немного можем мыслить?
Роллбэки(многоверсионность) вносят накладные расходы, и для систем OLTP не нужны, про то и речь шла. И грязные блоки вы упоминули не к месту, не с той стороны, так сказать. Признайте это.
О чем тут спорить? Оракл тащит фактически два журнала транзакций.
Sybase/mssql - один(и для отката и для вкатывания транзакций).


[..]
>На что Я привел, цитату, что В алгоритм многоверсионности входит и >игнорирование
>Незавершенных транзакций.
>Резюмируя, ваше заявление, выходит, что недостатком Оракла является >то, что он не позволяет видеть результата незавершенных транзакций.
>Вот собственно и все, т.е. вы просто не знали,
>что такое мультиверсионность, и что она состоит из двух частей.

Да вы шутите. Не знал! Любая СУБД по умолчанию работает в таком режиме. И никто не выжил из ума, чтобы наряду с одной системой управления транзакциями вводить еще одну. Если сервер не позволяет видеть запросу закоммиченные после запуска запроса строки, то подумайте сами, неужели он может позволить видеть не закоммиченные?
Он же из снимка берет. Представьте, что sybase бы поменял алгоритм управления транзакциями(уровнями изоляции) с использования блокировок на многоверсионность. - Чтобы вы сказали, для чего он это сделал?
Наверное, для того, чтобы получить что-то новенькое. - И этим новеньким был бы запрет "видения" закоммиченных после запуска запроса строк без использования блокировок(версия базы на момент запуска).
[..]
>>называется уровнем изоляции (isolation level).
>>Цитата:
>>********************
>>Isolation level определяет, могут ли операторы транзакции видеть >>результаты других одновременно выполняемых незавершенных и/или >>завершенных транзакций.
>
>********************
>А уж алгоритм многовариантности реализует два различных уровня >изоляции.

Еще до принятия SQL92 оракл поддерживал нормальную работу с СУБД.
Фактически покрывая (и перекрывая возможности конкурентов)все уровни изоляции(сериализуемость для read only- она чаще только для этого и нужна).
Эти стандарты уже потом за уши притянули, и все равно у Оракла они работают по своему. Это так же как семиуровневая модель сетевого взаимодействия. В одной из книг я читал, что число уровней определилось числом коммитетов учавствующих в принятии стандарта :).
SQL2 в части уровней изоляции заточен на стандартную схему СУБД,
которая для изоляции транзакций использует блокировки.



>Впрочем, если есть желание, предлагаю поспорить на эту тему со >Стивом Бобровски,
>Объяснить ему, что он не прав. Мне уже времени жалко.
Да фиг с ним, с Бобровски этим. Нельзя выдергивать куски чьих-то мыслей и вставлять их к месту и не к месту. Да многоверсионность (у оракла нет другой системы управления транзакциями) запрещает грязное чтение. НО ВВОДИЛДАСЬ ОНА НЕ ДЛЯ ЭТОГО. Запрет грязного чтения,- это само собой разумеющееся для любой СУБД.

>
>Если есть желание продолжить дискуссию по теме вашего,
>мягко сказать, неточного заявления:

Я так не думаю.

>-----------------------------
>Оракл только на стек по умолчанию мегабайт.
>-----------------------------
>Прошу привести документально подтвержденные, чем нибудь сведения.
>Может быть инициализационными параметрами, может быть ссылкой на >раздел
>Оракл документации. Что есть это за умолчание - Оракл установил?
>В общем, раз так заявляете, значит, сами знаете, как, я надеюсь, >доказать.
>Только не надо приводить данные из статей создателей какой-нибудь >системы какого-нибудь банка.

Ниже приводится кусок из доки.
А то, что V$sesstat фигню показывает, это вы у Бобровски спросите.
Память можно смотреть с помощью команды ps.
Только надо учитывать, что серверному процессу цепляется разделяемая память, равная размеру SGA ( SELECT SUM(value) FROM v$SGA).
Поэтому из размера выданного ps надо вычесть size of SGA.

minus EXECUTABLE
- 1,000 - размер стека выполнения серверного процесса - здесь получается 1000 страниц по 4K = 4Mb. У меня так и получилось.
Думаю эта величина может быть больше или меньше, но не меньше 1Mb.
Можно также посмотреть память другими командами, выдающими общий размер памяти, до коннекта и после(на однопользовательской базе).
Я задал вопрос на ixora, может ответят. К сожалению, я не нашел статью, в которой описывалось как можно уменьшить размер стека(хотя в ней не рекомендовалось это делать если памяти хватает).

Обещанный кусок из стандартной доки:

Detecting Memory Allocation Problems
When you use operating system tools to examine the size of Oracle processes, such as ps -efl or ps -aux on UNIX, you may notice that the processes seem large. To interpret the statistics shown, determine how much of the process size is attributable to shared memory, heap, and executable stack, and how much is the actual amount of memory the given process consumes.

The SZ statistic is given in units of page size (normally 4KB), and it normally includes the shared overhead. To calculate the private, or per-process memory usage, subtract shared memory and executable stack figures from the value of SZ. For example:

SZ
+20,000

minus SHM
- 15,000

minus EXECUTABLE
- 1,000

actual per-process memory
4,000

In this example, the individual process consumes only 4,000 pages; the other 16,000 pages are shared by all processes.

See Also:
Oracle for UNIX Performance Tuning Tips or your operating system documentation -- Нигде не нашел.

In this example, the individual process consumes only 4,000 pages; the other 16,000 pages are shared by all processes.

Думаю тут описка, стек все-таки процессу принадлежит. "Шарится" SGA- буферы, библиотеки,...

Не злись, аноним-оракл. Все будет хорошо.

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


Oracle Server
for Digital Unix

----------------------------------------------------------------------------

Patch Set Notes

Version 7.3.4.4



Wrong Results 7344 450317+ No warning give if PRO* selects 3 columns into 2
host variables.

ORA 600 [12025], ORA-7445 core dump in srsget, or
7344 566198+ wrong results from queries which give an execution
plan which has a non-repositionable SORT operation
within a Nested-Loops join.

>а что такое read commited?
>Это не один из уровней изоляции?
Именно, обычно это режим по умолчанию для любой СУБД.
Но опять же в Оракле он работает более гибко.
Читает строки закоммиченные только до запуска
запроса и при этом не использует блокировок.
В MSSQL неакуратно написанный SELECT (или недофетченный) может надолго заблокировать большой кусок таблицы (или всю ее) от изменений.

to anonymous-Oracle (*) (2001-03-25 19:36:26.0)


>To Nait,
>
>Забыл, про тестирование на собеседовании,
>Вопросы на фундаментальные темы не показывают возможностей >претендента.
>Уже замечено, просто предлагаю посмотреть одену из видеолекций по
>Oracle Certified Profeccional Exam на technet.oracle.com. Точно не >помню, но кажется по SQL PL/SQL.
>Так там лектор говорит, что тесты и реальная жизнь большая разница.
Ну вопросы я не совсем стандартные задаю. И потом, если человек не знает основ, он мне не нужен. И даже стандартный тест таких сразу отсеевает. В сад их, нафиг всех в сад. Я привел примеры первых вопросов. Далее, если стоит продолжать разговор, вопросы могут быть интереснее(к сожалению таких почти нет, все поустроились и не сдернишь с места).
Если DBA не знает что такое checkpoint, то это не DBA, а большая БЯКА.
Значит он понятия не имеет о том, как происходит востановление базы после мягкого и любого другого сбоя.
Таких близко к базе ньльзя подпускать. Это основы, причем общие для всех СУБД, даже для не реляционных (реализация может быть разной, но создаются для одной цели).
Не велика честь изучить shell. Любой птэушник(всякие техникумы) на это способен. Обычно такие горлопаны дальше и не продвигаются. Таким что поток, что процесс, что свопинг, что пэйджинг, что виртуальная память, что разделяемая (я серьезно пачками таких наблюдал), что стек, что вилка(fork в смысле) что ложка, что ..., но спецами юниксоидными себя считают крутыми (знаю shell+vi !!!) . А вот въехать в работу СУБД, не всякий может.
Кругозор требуется. Иначе такой DBA не сможет поднять базу в случае нестандартных проблем( если он не знает что такое checkpoint, он не будет знать и про серийный номер транзакции), здесь скрипты не помогут, надо будет делать неполное востановление ручками. Не сможет ее оттьюнить, будет мычать что-то нечленораздельное, и знание скриптов, и горящие праведным юниксоидным гневом глаза тут не помогут. А ведь именно за это им платят неплохие бабки(в смысле не за горящие глаза). Чтоб ничто не рухнуло, а если рухнет чтоб поднял, чтобы все летало. При этом DBA особо не нагружен текущей работой (в нормальных конторах).
Тут надо сказать, что есть разновидность "спецов", которые вам раскажут про свое представление внутренней работы оракла, про X-таблицы выложат много знаний, про то, как устроены блоки внутри базы.... про недокументированные параметры в init.ora, ...internals.
Послушаешь, начинаешь проникаться уважением, и задаешь глупый вопрос...
о том, что происходит по commit, и когда такой спец заряжает, что DBWR(или еще лучше серверный процесс!) пишет (фиксирует) данные в tablespace, тут вообще весело становится. Дальше больше, ей-богу цирк. И про согласованное чтение ТАКОГО пораскажут!
Таких спецов по ораклу, да и вообще по СУБД - море(и со стажем кстати тоже пачками).
Вообще основы важны, без фундамента не будет здания.
Если программер не знает, что такое рекурсивный алгоритм, то это как? Или где? Или на хрен он кому тогда нужен?
Если проектировщик не слышал о UML то, что он там на проектирует?Везде нужны профи. Вы же не пойдете к дантисту, который не закончил вуз, и к примеру не знает о последствиях флюса? Или нерв вам перечикает какой, что всю морду перекорежит?
Нет, оно понятно конечно, тут морда не своя вроде. Поэтому можно и про скрипты побалакать. Кстати, профессионализм особенно актуален для Oracle. MSSQL/Sybase являясь не менее серьезными СУБД, требуют меньшего внимания. Да и параметров, возможностей по настройке у них гораздо меньше.

To Nait (ну или кто в MS SQL),
Здрасте!

Нет, я Токарева с Окуджавой не спутал.
Про зону и лагерный фольклор не я писал.

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

Приходится сейчас мне работать с и MS SQL Server.
Не могу понять одного.
В Оракле все понятно написал update, insert, delete и все понятно
commit навсегда, rollback назад.
А в MS SQL написал если как в транзакции
begin transaction ┘.
сommit transaction
то ясно, а если просто статамент,
что заканчивает статемент, окно закрыть что ли?
Вроде кнопок нет, а все уже как закоммичено.
Бред, какой то, а если я назад хочу, ошибку сделал.
Oracle

to anonymous-oracle (*) (2001-04-07 10:14:35.0)

>Нет, я Токарева с Окуджавой не спутал.
>Про зону и лагерный фольклор не я писал.
Сорри.

>А в MS SQL написал если как в транзакции
>begin transaction ┘.
>сommit transaction
>то ясно, а если просто статамент,
>что заканчивает статемент, окно закрыть что ли?
По умолчанию сервер в автокоммите работает.
Если вы предполагаете, что надо будет что-то откатывать
делаете (т.е. вам нужна транзакция) то:

begin tran
1
2
3
if <> then Rollback
commit tran

если хотите чтоб как в оракле было, только коммиты писать,
то надо установить SET IMPLISIT TRANSACTION в ON.
Либо в настройках сервера, либо можно это
делать сразу после коннекта для каждой сессии.

Кстати, я забыл упоминуть о еще одном удобстве в Symase/MSSQL/Informix. В этих СУБД может быть на одном сервере не одна база. Т.е. идеология словаря базы другая.
Есть мастер база, в ней хранится информация о других базах и общие настройки, но есть множество других баз. Т.е. их можно создавать неограниченно. При этом они имеют свои дневники базы(системные таблицы о таблицах, колонках,...) это очень удобно в сопроводении и эксплуатации(одна рабочая, база другая тестовая - все в одном сервере).Чтобы съэмулировать это в Oracle надо запускать инстансы, а каждый из них большой обжора. Т.ю. много их не запустишь, даже два(при промышленных настройках SGA) это уже не рулез.
В sybase/informix/MSSQL баз может быть открыто сколько угодно.

To Nait,
> По умолчанию сервер в автокоммите работает.

Агааа! Понятно, спасибо!
То-то я смотрю, фигня какая то получается, просто непривычно

А на оракле видел где в продакшен 2 базы работали ничего, нормально,
не жаловались особо, хотя, конечно, чудес не бывает и каждая БД свое положенное
кушала. Сервера другого такого мощного не было.
Вначале БД одна была, но две совершенныо разные системы,
и жаловались пользователи одной системы,
она должна быть очень оперативной, а на второй люди
лихо ⌠эксперементировали■ и перегружали часто. Те в конце-концов возмутились
и для них слепили их самостийную базу.
Oracle

To сам себе,

> Агааа! Понятно, спасибо!
> То-то я смотрю, фигня какая то получается, просто непривычно

Для твоего любимого оракла тоже есть

SET AUTOCOMMIT ON|OFF по умолчанию OFF

Oracle