Вопрос о базах и кеше.

[Dmitry67]

ВОт и у меня вопрос возник по SQL serverу. Впрочем есть вопросик и для остальных

Имею две квери, A и B.
Кверь A выполняется первый раз 50sec, второй раз 5 sec
Кверь B выполняется 40sec, второй раз 10 sec
Понятно, работает кеш

При запуске их последовательно A,B выполняется 50sec.
Ага, кеша мало
Пытаюсь дать SQL serverу больше памяти
Скорость увеличивается но больше 1.7Gb расти не хочет
Хотя памяти на сервере значительно больше
Почему ?

Кстати, на DB2 и Oracle - они читают все мимо кеша операционной системы ?

[Dmitry67]

Кажется сам понял: надо включить AWE

[vc]

Кстати, на DB2 и Oracle - они читают все мимо кеша операционной системы ?

It depends.

In Unix, one has to use either raw partitions or the 'forcedirectio' option (Solaris) when mounting a file system in order to avoid OS buffering.

In Windows, Oracle always bypasses the OS cache by using the FILE_FLAG_NO_BUFFERING/FILE_FLAG_WRITE_THROUGH options.

Rgds.

[Dmitry67]

А на Linux есть forcedirectio ?

Кстати любопытно
С AWE sql server в Task Manager выглядит совсем крошечным
То есть AWE память 'не считается'...

[zVlad]

ВОт и у меня вопрос возник по SQL serverу. Впрочем есть вопросик и для остальных
..........
Кстати, на DB2 и Oracle - они читают все мимо кеша операционной системы ?

Shortly saying DB2 reads pages from disks without using what you call “кеш операционной системы “ (which is actually not defined in MVS at all). Of course, DB2 has caches (called as Buffer Pools) to store pages in memory for better performance. For those BPs, DB2 co-operates with MVS very close. There are MVS’s Data Spaces (it could be considered as an analog of “кеш операционной системы “) and they could be used by DB2 for BPs (this is just one of few ways of how BPs could be implemented. With 64-bit addressing in place, ways of having BPs are totally reviewed. But all pervious cache related techniques are kept.)
In our shop we have few tables which are completely resided in CPU memory all time. It was made to meet response time requirements.

By the way, DB2 has a “cache” for dynamic SQL statements. That means when SQL comes in for first time, DB2 will compile it and store it in “dynamic SQL cache”. If the same SQL will come in again, DB2 will rather use already prepared and stored SQL than do it again.
Do Oracle and/or MS SQL have stuff like that?

[YellowMan]

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

[Dmitry67]

By the way, DB2 has a “cache” for dynamic SQL statements. That means when SQL comes in for first time, DB2 will compile it and store it in “dynamic SQL cache”. If the same SQL will come in again, DB2 will rather use already prepared and stored SQL than do it again.
Do Oracle and/or MS SQL have stuff like that?

Разумеется
Более того, если выполнять запросы типа
select ... where A=45 and B=66
select ... where A=233 and B=66
select ... where A=9 and B=66

то вскоре заметишь что MS SQL создал план запроса для
select ... where A=@p1 and B=66

[vc]

А на Linux есть forcedirectio ?

...

Last time I dealt with Oracle on Linux (about a year ago), there was no such option.

Rgds.

[zVlad]

Dmitry67, in DB2, it is the same, but queries:

'select c1 where A=? and B=?'

, and

'select c1 where A=? and B=? '

will be considered as two different queries.

[verzlo]

Кажется сам понял: надо включить AWE

Абсолютно верно ,включите AWE и дополнительно включите 3G switches.
По умолчанию в Виндах мах размер процесса в памяти не может превысить 2 Гб (включая виртальную память для него - поэтому реальной памяти вы видите тольк 1.7 Гб примерно). Если включить 3G switch - то
этот лимит увеличится до 3 Гб. При включении AWE - можно неограниченно увеличивать размер процесса в пределах свободной памяти, но тут есть ньюанс - буфера памяти будут маппится в "верхней" памяти > 4 Гб, а в обычной будут сохраняться пойнтеры наних.. Это немного увеличивает CPU overhead - в нашем случае на 15-20 % .

[Dmitry67]

Кажется сам понял: надо включить AWE

Абсолютно верно ,включите AWE и дополнительно включите 3G switches.
По умолчанию в Виндах мах размер процесса в памяти не может превысить 2 Гб (включая виртальную память для него - поэтому реальной памяти вы видите тольк 1.7 Гб примерно). Если включить 3G switch - то
этот лимит увеличится до 3 Гб. При включении AWE - можно неограниченно увеличивать размер процесса в пределах свободной памяти, но тут есть ньюанс - буфера памяти будут маппится в "верхней" памяти > 4 Гб, а в обычной будут сохраняться пойнтеры наних.. Это немного увеличивает CPU overhead - в нашем случае на 15-20 % .

Да, спасибо
А вообще deja vu - помните XMS, EMM386, оптимизация QEMM386

[lozzy]

Да, спасибо
А вообще deja vu - помните XMS, EMM386, оптимизация QEMM386

64 бита не за горами

[hren]

Last time I dealt with Oracle on Linux (about a year ago), there was no such option.

Direct io для файловых систем поддерживается на уровне ядра в Linux RH Enterprise Linux AS (бывший Red Hat Linux Advanced Server). Возможно и где-то еще. В принципе, он доступен для файловых систем xfs (точно) и, возможно, ext3 (не уверен).

В большинстве случаев использование direct io в Oracle актуально для OLTP приложений, с высоким уровнем io, при большом размере блочных буферов СУБД, особенно при использовании высокоскоростных внешних дисковых массивов со своим большим кэшем и большой пропускной способностью контроллера. Может заметно уменьшить нагрузку на процессоры сервера.

[hren]

By the way, DB2 has a “cache” for dynamic SQL statements. That means when SQL comes in for first time, DB2 will compile it and store it in “dynamic SQL cache”. If the same SQL will come in again, DB2 will rather use already prepared and stored SQL than do it again.
Do Oracle and/or MS SQL have stuff like that?

Oracle имеет очень развитую систему кэширования запросов. Кэшируются курсоры на уровне сессии, кэшируются запросы (несколькими способами) в общих областях памяти. Это механизм настраивается большим количеством параметров и работает весьма эффективно, если у приложения достаточно велик коэффициент переиспользования запросов. В противном случае contention в областях буферизации запросов приводит иногда к необходимости уменьшать их размер.

[zVlad]

By the way, DB2 has a “cache” for dynamic SQL statements. That means when SQL comes in for first time, DB2 will compile it and store it in “dynamic SQL cache”. If the same SQL will come in again, DB2 will rather use already prepared and stored SQL than do it again.
Do Oracle and/or MS SQL have stuff like that?

Oracle имеет очень развитую систему кэширования запросов. Кэшируются курсоры на уровне сессии, кэшируются запросы (несколькими способами) в общих областях памяти. Это механизм настраивается большим количеством параметров и работает весьма эффективно, если у приложения достаточно велик коэффициент переиспользования запросов. В противном случае contention в областях буферизации запросов приводит иногда к необходимости уменьшать их размер.

In DB2 I could find just three parameters to control Dyn SQL Cache, one of them is optional - Data Space Size (if you wish Data Space for Dyn Cache), Second one is to say if you really wish to use Dyn Cache (YES, or NO), and last one to limit number of dyn stmts be kept past commit point for each single application.
I have never heard about contentions related to usage of Dyn SQL Cache.