Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 26   вперед  Ctrl
 Re: Провал операции Yukon  [new]
Nikolay Kulikov
Guest
2Зл0й: У вас просто лицензии нет в jar файле. Попробуйте взять JDBC драйвер от DB2 Connect или с самой 390 машины.

P.S. Вышесказанное есть моя личная точка зрения и не может служить официальным заявлением компании IBM
24 май 04, 14:26    [696667]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
M
Guest
Во-первых необязательно пихать строки в индекс, тем более в кластерный, а во-вторых размер ключа для индекса ограничен 900 байтами. Так что страничная организация и индексы судя по всему никак не связаны.
Выборка диапазонов обычных данных с помощю индекса. Сам по себе индекс может быть каким угодно, хоть числовым. При сканировании диапазонов Сиквел умеет оптимизировать выборку страниц обычных данных (а не страниц индекса) используя внутренние страницы индекса, чему очень помогает ограничение размера записи одной страницей, тхника называется Readahead. Размер и характер ключа индекса никакой роли не играет.

блокировка на уровне записи это очень плохо и она никому не нужна.
Это опять-таки Ваша интерпретация или цитата?
Строго говоря, блокировка на уровне записи, не то, чтобы не нужна, но это далеко не всегда самый лучший вариант. Может быть они только это имели ввиду?
24 май 04, 14:38    [696707]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Merle
в документации на тот же оракл ясно сказано, что стандартные размеры страниц смотрите в описании Оракла под конкретную ОС. Так что составители документации Оракла в этом вопросе со мной солидарны, то есть оптимальный размер страниц данных от ОС все-таки зависит


Ссылочку можно, где написана эта чушь?

Merle
Во-первых " Oracle stores data in data blocks (also called logical blocks, Oracle blocks, or pages). " (c) Oracle® Database Concepts.

Pages употребляется в документации Oracle касательно синонима data block только в двух местах в Concepts. И то, подозреваю, что для граждан, не знакомых с concepts и терминологией - чтобы пояснить суть.

Merle
Да и далее во всей документации слово pages используется с завидной регулярностью.


Ссылочку можно хоть еще одну, где page=data block по смыслу?

Вы опять пудрите мОзги несведущим гражданам, т.к. судите с умным видом о том, в чем, как я убедился, абсолютно не разбираетесь.

О терминологии. В рамках MS SQL есть понятие страница данных, ему примерно соответствует понятие блока данных (data block) в Oracle. И давайте не будем путать и смешивать понятия.
24 май 04, 18:40    [697495]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Borland
Member

Откуда: $HOME
Сообщений: 15839
2 Merle : Размер блока данных в Оракле равен n*FileSystem_block_size, где n - любое натуральное число. И именно так сказано в доке, несмотря на то, что это явно следует из описания физической и логической структур оракла. И такое название является более корректным, чем "страница".

-----
Все великие дела совершаются в командной строке
24 май 04, 18:49    [697512]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
Какое отношение имеет размер блока ФС (которой может и не быть вообще) к размеру блока данных Oracle? Где в доке сказано?
24 май 04, 18:58    [697528]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
M
Guest
В огороде бузина, а в киеве дядька.

Ссылочку можно, где написана эта чушь?
;)))) Где-то в консептс, лень искать...

не знакомых с concepts и терминологией
Об чем и речь. Еще раз говорю, мне абсолютно пофигу как это называется в оракле, поскольку теории и в технической литературе это называется pages.

И давайте не будем путать и смешивать понятия
Я не путаю и не смешиваю.

Какое отношение имеет размер блока ФС (
Я где-то что-то говорил про размер блока FS?
24 май 04, 19:46    [697601]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Про страницы и блоки. В разных книжках это называют по разному. В программировании терминологический спор ИМХО неуместен. "Называй хоть горшком, только в печку не ставь". ИМХО термин "блок" в контексте СУБД более удачен. Потому, что позволяет отличить блок данных СУБД от страниц виртуальной памяти. ОС имеющая механизм виртуальной памяти может "кидаться" страницами из оперативной памяти на диск и обратно мо мере необходимости. Но это - ОС, а не СУБД. Последняя же может использовать различные способы "кидания" данных с диска в оперативную память и обратно. В частном случае на виндах это может делаться "постранично", если используется memory-mapped файл. В общем случае это может делаться различными "порциями" как при участии фаловой системы, так и в обход её. Соответственно, в общем случае про размер "порции" данных которыми СУБД обменивается между диском и памятью можно сказать следующее:
- Он не зависит от размера блока файловой системы (ибо файловая система может вообще не использоваться)
- Он не зависит от размера страницы виртуальной памяти данной архитектуры (ибо переносимая СУБД может работать на разных архитектурах, и еще по ряду причин)

Как было правильно замечено выше, Оракл позволяет менять размер блока, т.е. "порции" которой осуществляется обмен между памятью и диском. Это позволяет его гибко настраивать. На Data Warehouse базах блок ставят побольше, а на OLTP выбирают исходя из платформы, типа используемого ввода/вывода итп. Скептикам, не верящим в изменение размера блока советую книжку Дансмура и Дэйвиса про программирование на С под Юниксом. Там вопросы буфферизации и выбора оптимального размера блока рассмотрены весьма подробно.

А с мелкософтом все понятно - СУБД жестко завязана на конкретную ОС (винды) и конкретную архитектуру (х86). Поэтому размер блока = размер страницы, и фиксирован. В результате и имеем весь этот confusion в терминологии.
24 май 04, 22:08    [697689]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
2Зл0й
автор
А с мелкософтом все понятно - СУБД жестко завязана на конкретную ОС (винды) и конкретную архитектуру (х86). Поэтому размер блока = размер страницы, и фиксирован. В результате и имеем весь этот confusion в терминологии.

Всё-таки плохо по слухам :-)
В виндах и х86-процессорах страница - 4К, в MSSQL блок - 8К
25 май 04, 10:36    [698107]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Borland
Member

Откуда: $HOME
Сообщений: 15839
2 Scott Tiger :

One data block corresponds to one or more operation system blocks allocated from an existinf data file

Enterprise DBA Part 1A, chapter 8.

Если блок ОС - это не блок ФС, которая используется данной ОС, то тогда что?

-----
Все великие дела совершаются в командной строке
25 май 04, 11:19    [698297]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nikolay Kulikov
Guest
2Borland: Блок FS не есть блок OS
25 май 04, 16:36    [699763]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
juha_teuvonnen
Guest
ОК, размер блока MS SQL = 2*размер страницы, уговорили. Признаюсь, что был не прав. Перепутал с размером страницы по умолчанию в Solaris/UltraSparc. Тыщу лет ничего не делал под винды и х86, вот и подзабыл. Суть от этого не меняется. Разработчики МС зафиксировали один конкретный удобный им размерчик и все. Кому не подходит - тем не повезло. Подход ИМХО нездоровый.

Про блоки Оракла и ФС:

Оракл может работать в обход файловой системы. Например на Юниксе он может работать с raw device (типа партицию отдаешь ему, а он сам ей рулит). В этом случае Ораклу до лампады какой размер блока у файловой системы. Он сам будет читаль/писать на raw device Оракловыми блоками. Грубо говоря, в данном случае Оракл - сам себе файловая система. Со своим размером блока, кэшом журналированием (того что ему надо журналировать а не чего попало) и всеми пирогами.

В случае если Оракл использует файловую систему, то размер блока ФС ему тоже не уж важен. Невероятно, но факт. Ибо в современных ОС (например Solaris и SVR4 Юниксы) на нижнем уровне ОС операция чтения файла осуществляется через мэппирование его в память постранично. А традиционный юниксовый API файловой системы надстроен над mmf-интерфейсом сверху. В случае если кэширование ФС не используется (если ОС позволяет) то Ораклу все равно какой размер блока ФС. Ему скорее интересно какой размер страницы на данной архитектуре. А сколачивать блоки из 1,2 и более страниц и управлять кэшом Оракл может и сам. Есть такая точка зрения, что Оракл - штука настолько самодостаточная, что ей от ОС кроме ядра и volume manager'a ничего не надо. Оракловый appliance так и делается.
25 май 04, 20:01    [700407]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
juha_teuvonnen
Оракл может работать в обход файловой системы. Например на Юниксе он может работать с raw device
MSSQL то же умеет работать с raw device в обход файловой системы.
25 май 04, 20:24    [700432]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
2juha_teuvonnen
автор

Про блоки Оракла и ФС:

Оракл может работать в обход файловой системы. Например на Юниксе он может работать с raw device (типа партицию отдаешь ему, а он сам ей рулит). В этом случае Ораклу до лампады какой размер блока у файловой системы. Он сам будет читаль/писать на raw device Оракловыми блоками. Грубо говоря, в данном случае Оракл - сам себе файловая система. Со своим размером блока, кэшом журналированием (того что ему надо журналировать а не чего попало) и всеми пирогами.

В случае если Оракл использует файловую систему, то размер блока ФС ему тоже не уж важен. Невероятно, но факт. Ибо в современных ОС (например Solaris и SVR4 Юниксы) на нижнем уровне ОС операция чтения файла осуществляется через мэппирование его в память постранично. А традиционный юниксовый API файловой системы надстроен над mmf-интерфейсом сверху. В случае если кэширование ФС не используется (если ОС позволяет) то Ораклу все равно какой размер блока ФС. Ему скорее интересно какой размер страницы на данной архитектуре. А сколачивать блоки из 1,2 и более страниц и управлять кэшом Оракл может и сам. Есть такая точка зрения, что Оракл - штука настолько самодостаточная, что ей от ОС кроме ядра и volume manager'a ничего не надо. Оракловый appliance так и делается.


Ну сколько раз уже писали - для MSSQL всё то-же самое - и мэппирование в память постранично, и т.д. И даже "Традиционный виндовый API файловой системы надстроен над интерфейсом виртуальной памяти сверху.". Замените Оракла на MSSQL, а в список "современных ОС" добавьте винды - текст останется верным.
За исключением того, что размер блока в MSSQL фиксирован, а с диском MSSQL работает так даже без использования raw device.
25 май 04, 21:16    [700493]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
автор
а с диском MSSQL работает так даже без использования raw device


Гы Гы Гы, на оленьих упряжках или голубиной почтой ?
Сам то понял, что сморозил ?
25 май 04, 21:40    [700518]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
2Gluk (Kazan)
Я по профилю смотрю, вы знаток Win-платформ и WinAPI знаете наизусть? :-)))

Боюсь огорчить, но действительно с диском MSSQL работает так даже без использования raw device. Не принимайте-уж близко к сердцу... Зато в Оракле курсоры быстрые :-)
25 май 04, 22:06    [700559]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Не желаю вступать с Вами в полемику, но фраза была на удивление корявая.
Вообще меня эта тема весьма веселит. Кстати я довольно неплохо знаю WinAPI ;)
25 май 04, 23:15    [700635]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Я и не спорю с тем, что MS SQL умеет работать с диском через MMF файлы. Так сказать "в обход" файловой системы, и особенно ее кэша. Я другого не понимаю, зачем жесткое ограничение на блок=8К. Какой в этом ограничении сокровенный смысл? Надеюсь уважаемые оппоненты не будут утверждать что 8К - универсальный размер блока для СУБД? Или будем устраивать экскурс по разделу "Операционные системы и буфферизация". Чисто из практического ораклового опыта могу сказать что для аналитических СУБД (DW, DSS, OLAP) большой размер блока улучшает производительность. Думаю в родственном MS SQL Сайбэйсе, где размер блока можно менять, расклад такой же как и в Оракле. А в MS SQL - низзя. "Патчиму, да?" Низзя и все.
25 май 04, 23:44    [700658]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Уважаемому Алексею на заметку,

Работа с файлом и работа с сырой партицией (raw device) "напрямую" - разные вещи. Любая запись в файл (синхронная/асинхронная, с кэшированием или без, с использованием MMF-интерфейса или без ) всегда медленнее чем запись на "сырую партицию". Потому, что ФС при записи в файл еще должна поддерживать целостность своих метаданных. А СУБД эта лишняя нагрузка зачем?

Кстати, в MS SQL авторитеты рекомендуют использовать "сырые партиции" для подъема производительности операций пишущих в базу. Говорят прирост аж на целых 20%.

alexeyvg
а с диском MSSQL работает так даже без использования raw device.

Так что вы тут погорячились.
26 май 04, 01:21    [700726]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
anjey
Member

Откуда: Прокопьевск
Сообщений: 933
для модератора

этот топик пора выносить в отдельный форум, на отдельном сайте
26 май 04, 04:55    [700784]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
2Зл0й
автор
Я другого не понимаю, зачем жесткое ограничение на блок=8К.

Я тоже не понимаю. Полезно было-бы иметь бОльшую гибкость. Может быть, это позволило оптимальнее написать код и всё такое, но мы про это не знаем.

автор
Работа с файлом и работа с сырой партицией (raw device) "напрямую" - разные вещи. Любая запись в файл (синхронная/асинхронная, с кэшированием или без, с использованием MMF-интерфейса или без ) всегда медленнее чем запись на "сырую партицию". Потому, что ФС при записи в файл еще должна поддерживать целостность своих метаданных. А СУБД эта лишняя нагрузка зачем?


Я не согласен. Никакой целостности своих метаданных ФС при записи в файл поддерживать не должна. Файл лочится, т.е. ФС получает команду отказать в запросах на доступ к файлу всем приложениям. Серверу передаётся список блоков этого файла на разделе. И серер их использует; ничего при работе с файлом в метаданных не меняется.

Разумеется, при изменении размера файла необходима помощь ФС, и это будет медленно. Но я думаю, изменение сырой партиции тоже не быстро, и возможно, даже не может производится "прозрачно" для сервера СУБД.

автор
Кстати, в MS SQL авторитеты рекомендуют использовать "сырые партиции" для подъема производительности операций пишущих в базу. Говорят прирост аж на целых 20%.

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

Тут кто-то делал тесты, вроде разницы большой не заметил - в пределах погрешности измерений.
26 май 04, 10:16    [701073]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
Мне кажется, что вагоноуважаемые не рассматривают более важный аспект влияния размера блока БД на производительность - тот факт, что блок не только является атомарной единицей I/O (хотя никто не отменял многоблочного чтения), но и является атомарной единицей хранения информации на физическом уровне. А это приводит к тому, что при увеличении размера блока в нём помещается большее количество строк, и при росте количства DML растёт конкуренция за изменение служебной информации, находящейся в блоке.
26 май 04, 10:31    [701122]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
2Scott Tiger
Это правильно, но речь о том, что хорошо-бы регулировать этот параметр - для чтения большой блок очевидно лучьше.
26 май 04, 10:36    [701135]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 alexeyvg

т.е. по Вашему разница между записью в сильно фрагментированный файл и на сырую партицию заключается только в наборе промежуточных драйверов ?
Смелое заявление от знатока WinApi

А размещать таблицы с данными на пакованных томах вообще маразм
26 май 04, 10:37    [701141]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
2Gluk (Kazan)
автор
т.е. по Вашему разница между записью в сильно фрагментированный файл и на сырую партицию заключается только в наборе промежуточных драйверов ?

Разница не принципиальна, если, конечно, не делать сильно разных начальных условий - типа, "давайте сильно фрагментируем файл".

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

автор
А размещать таблицы с данными на пакованных томах вообще маразм

Согласен.
26 май 04, 12:07    [701460]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Если разница между raw device и mmf-file "не принципиальна", тогда откуда дополнительные 20% производительности операций пишущих в базу берутся при переводе MS SQL с файловой системы на сырой девайс?
26 май 04, 21:17    [703471]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 26   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить