ЧАВО

запустите сбор статистики: 

/etc/rc2.d/S21perf start 

A:  Некоторые программы, например iostat, sar могут выдавать имена дисков в формате sdn. Предположим, мы имеем следующий вывод :

  iostat 5
   tty        sd21          ssd0          ssd1          nfs1           cpu
 tin tout kps tps serv  kps tps serv  kps tps serv  kps tps serv   us sy wt id
   0    2   0   0    0   31   4   13   20   3   70    0   0    0    0  2  1 97
  

Узнаем, что означает ssd0:

oracle@kakadu>grep " 0 " /etc/path_to_inst | grep ssd
"/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w21000004cf8f8231,0" 0 "ssd"

И дальше

oracle@kakadu>ls -la /dev/rdsk/*s2 | grep "pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w21000004cf8f8231,0"
lrwxrwxrwx 1 root root 74 æÅ× 20 2003 /dev/rdsk/c1t1d0s2 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w21000004cf8f8231,0:c,raw
 

О ! ssd0 == c1t1d0

Для этой же цели можно воспользоваться и perl утилитой mapdev из состава Solaris-0.05 by Alan Burlison

oracle@kakadu>mapdev
nfs1 is an alias for kakadu:vold(pid272)
nfs2 is an alias for elephant:/home/aroschin
sd21 is an alias for c0t6d0
ssd0 is an alias for c1t1d0
ssd1 is an alias for c1t0d0

или mapdev -explorer <имя директории>

A:  Пакет, содержащий Sun Explorer, называется SUNWexplo. Взять его можно на интернет-сайте Sun. 

gzip -d SUNWexplo.tar.Z

tar -xvf SUNWexplo.tar

pkgadd -d . SUNWexplo

Будет задано много вопросов об номерах контрактов и серийных номерах, если что-то знаете - самое время признаться в этом. Но если нет - ничего страшного. Эта информация нужно только для support'а. См. также Детальную инструкцию по установке.  

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

 # /opt/SUNWexplo/bin/explorer -w sysconfig 
óÅÎ 12 11:12:33 kakadu[1084] explorer: explorer ID: explorer.83186c62.kakadu-2003.09.12.14.12
óÅÎ 12 11:12:33 kakadu[1084] patch: RUNNING
óÅÎ 12 11:12:40 kakadu[1084] pkg: RUNNING
óÅÎ 12 11:12:44 kakadu[1084] sysconfig: RUNNING
óÅÎ 12 11:13:19 kakadu[1084] sysconfig: exited: AP not installed
óÅÎ 12 11:13:24 kakadu[1084] explorer: data collection complete
óÅÎ 12 11:13:25 kakadu[1084] explorer: removing previous explorers from /opt/SUNWexplo/output
óÅÎ 12 11:13:25 kakadu[1084] explorer: Explorer finished

Приме обычного запуска explorer

 # /opt/SUNWexplo/bin/explorer

Результат обработки складывается в директорию /opt/SUNWexplo/output

Обработать его можно с помощью exlorer.sh

bash-2.03# /opt/oracle/packages/explorer.sh explorer.83186c62.kakadu-2003.09.12.15.36 | less 

Пример отчета, после обработки 

Если у Вас есть дисковые массивы то могут понадобиться доп. шаги. Так для массива T3 необходимо заполнить файл /etc/opt/SUNWexplo/t3input.txt :

# less /etc/opt/SUNWexplo/t3input.txt 
# Input file for extended data collection
# Format is HOST PASSWORD
/etc/opt/SUNWexplo/t3input.txt (END)

И запускать explorer с ключами -w all, t3extended, t3

A:  Итак, у Вас есть благородная цель, чтобы Ваша SGA была целиком в памяти. И Oracle, казалось, сделал для этого параметр lock_sga. Но если поставить этот параметр в init.ora для Oracle 8i и Solaris 8 то 

ORA-27126: unable to lock shared memory segment in core
SVR4 Error: 1: Not owner 

Оно как выясняется и правильно :). Потому как только root может это делать. И даже есть маленькая программка на С которую можно запустить после старта экземпляра. Но, давайте обратим внимание, что за память используется нашим экземпляром:

ipcs -im

 
IPC status from  as of Wed Dec  3 15:22:18 MSK 2003
T         ID      KEY        MODE        OWNER    GROUP ISMATTCH
Shared Memory:
m          0   0x50000bd9 --rw-r--r--     root     root        0
m       8705   0x20362024 --rw-r-----   oracle oinstall      189
m          2   0x672fffc4 --rw-r-----   oracle oinstall       27

Колонка ISMATTCH не пустая, что говорит о том, что используется ISM (Intimate shared memory) память. А ISM память организована таким образом, что она не может быть выгружена на диск. Другим ее преимуществом является то, что под нее не резервируется место в swap. Таким образом, я считаю, что если используется ISM - то нет необходимости делать lock SGA. Началось это счастье с Solaris 2.6.Читать подробнее.

Metalink тоже внес свою лепту в этот вопрос: DETERMINING WHICH INSTANCE OWNS WHICH SHARED MEMORY & SEMAPHORE SEGMENTS

A:  Механизм  Dynamic Intimate Shared Memory (DISM) позволяет приложению динамически изменять размер используемой разделяемой памяти (shared memory). Oracle 9i использует этот механизм для динамического перераспределения SGA памяти. И все было бы хорошо если бы не Solaris 8 bug (4675878). Он вызывает крайне высокое System CPU %, что видно в sar или vmstat.

Как workaround предлагается не использовать параметр sga_max_size вообще !!!.

Полностью проблема и ее диагностика описана в 

Очень рекомендую прочитать.

Сухой остаток: DISM должен использоваться только в Solaris 9 Update 2 или позже. 

A:  Нижеследующий способ был предложен Allan Packer, и оформлен в виде procmem.sh. Работает она так:

SID моей базы "portal"

procmem.sh -u oracle "oracleportal"

Processes                                   Kbytes Resident   Shared  Private
 
---------                                   ------ --------   ------  -------
 
Process Summary (Count)

  oracleportal (1)                         1114744  1096480  1095616      864
 
-----------------------------------------------------------------------------

File (Count)                                Kbytes Resident   Shared  Private
-----------                                 ------ --------   ------  -------
/usr/lib Shared Library Totals                1984     1800     1624      176
 
Other Shared Library Totals                   6312     1408     1224      184
 
Binary File Totals                           26544    13408    13336       72
 
Shared Memory Totals                       1079424  1079424  1079424        0
 
Anonymous Memory Totals                        480      432        0      432
 
-----------------------------------------------------------------------------

Grand Totals                               1114744  1096472  1095608      864

Смотреть нужно колонку Private. Рекомендуется правда поставить также пакет memtool, но разницы между ним и pmem я не заметил.

Первый вариант (0+1) плох тем, что в случае потери  любого диска, зеркало "разваливается". Требуется срочный ремонт. Но, для Disksuite описан вариант сборки только 0+1 !. 

Оказалось, что Disksuite сам реально внутри поддерживает 1+ 0, по крайне мере, когда все участвующие устройства одинаковы по размерам. 

Евгений Бобков проделал следующий эксперимент: На одном жестком диске был собран страйп из slice' ов 0,1,3 и страйп из слайсов 4,5, 6. Эмулировалось естественно 6 различных жестких дисков.

Далее, слайсы 0, 5, 3 убивались. Тем не менее, информация оставалась доступной. Это собственно и доказывает, что реально поддерживается 1 + 0.

Вот здесь приводиться подобный эксперимент:

http://www.sunmanagers.org/pipermail/summaries/2001-June/000824.html

А здесь две статьи про то как c помощью Disksuite  выполнять зеркалирование корневого(root) раздела:

http://www.sunhelpdesk.com/jmr_Mirroring_Boot_Drive_Solstice_Disksuite.htm

http://open-systems.ufl.edu/docs/fs/solaris_bootdisk_mirror.pdf

И рекомендую Admin's Guide to Solstice Disk Suite, особенно главу 7, TroubleShooting 

Вот что я имел в виду под словами  зеркало "разваливается": Будем рассматривать те же слайсы (эмулирующие физические диски) 0,1,3 и 4,5,6.  Для классического 0+1.

Предположим умирает слайс 0. Данные у нас есть на 4,5,6. Но. Механизм зеркалирования прекращает свою работу.  Он считает что половина зеркала требует ремонта. И ждет этого ремонта.  Данные будут продолжать писаться только на 4,5,6. Теперь если выйдет из строя любой из слайсов 4,5,6  то будет потеря данных. 

Формулируя более строго:

Для 0+1 "Если же одновременно выйдут из строя 2 любых члена разных зеркал, например слайсы 0 и [4|5|6], то будет потеря данных".

Для 1+0 "Если же одновременно выйдут из строя любые оба члена одного зеркала, например слайсы 0 и 4, то будет потеря данных".

A:  Действительно, что скрывается за колонкой free в vmstat ? 

man немногословен:

swap amount of swap space currently available
(Kbytes)

free size of the free list (Kbytes)

Ответ удается найти с помощью пакета MemTool. Исходные данные: На машине 2 Gb оперативной памяти, один экземпляр Oracle.

 
SQL> show sga

Total System Global Area 1105166496 bytes

 
 vmstat 2
 procs     memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr s0 s1 -- --   in   sy   cs us sy id
 0 0 0 1348808 406496 2  14  0  0  0  0  0  1  2  0  0  143  143  123  0  1 99 

# prtmem

Total memory:            1957 Megabytes
Kernel Memory:            188 Megabytes
Application:             1163 Megabytes
Executable & libs:         27 Megabytes
File Cache:               177 Megabytes
Free, file cache:         137 Megabytes
Free, free:               263 Megabytes

Считаем:  263 + 137 = 400. Таким образом free в vmstat - это сумма действительно свободной памяти и свободной памяти в файловом кэше. 

A:  Далее частичный перевод различных трудов Adrian Cockcroft, с небольшими добавлениями про особенности Solaris 8. Курсив - мой.

Объединяя RAM и выделенное дисковое пространство, swap хранит виртуальную память (virtual memory) системы. Каждая программа, которую Вы выполняете, занимает  некоторое кол-во виртуальной памяти.  Когда вся ваша виртуальная память будет занята приложениями, вы не сможете запустить новых приложений, а существующие также могут получить сообщение об ошибке, если им потребуется больше памяти. Физическая память - это то что Вы знаете как RAM системы. Если Вы займете всю RAM, ваша система может стать значительно медленнее, но все еще работать, поскольку "лишние" данные будут помещены в  swap. Физическая память содержит "текущий набор" виртуальной памяти, это означает часть ваших приложений, который выполняются на ЦПУ (CPU).

Вы обычно устанавливаете достаточно RAM для вашего основного приложения, или его части, активной в то или иное время. Вы можете иметь оконную системы, с большим количеством свернутых приложений, или находящихся в фоновом  режиме. У таких спящих приложений потихоньку отбирается используемый ими RAM и перемещается в swap на диск. Вы наверно наблюдали, что если открыть давно не использовавшиеся окошко, диск будет сильно трещать, ОС возвращает приложение в RAM.

Важно понимать, что swap объединяет полный размер всех выполняемых и спящих программ в системе. Когда в системе недостаточно swap пространства, может быть очень тяжело восстановить стабильную работу системы. Иногда,  вы можете обнаружить недостаток swap пространства потому что не можете войти как root, или выполнить команду kill для удаления процесса, который поглотил все swap пространство. 

Требования к пространству swap для баз данных

Используйте для начала размер swap равный 2 размерам RAM. (это утверждение повторяется везде и всеми, в том числе Oracle'ом. Но в Solaris 8 изменен принцип работы со swap, добавлен механизм priority_paging, что теоретически снижает требования к размеру swap. Также, если Ваша SGA находится в ISM памяти, то под нее не происходит резервирование места в swap. Итого, выделите 2-х кратный размер своей физической  памяти, если позволяет дисковое пространство. Но это более чем достаточно)

Paging & Swapping 

Solaris использует 2 типа пейджинга  своей системе вирутальной памяти. Это своппинг (swapping), выгрузка все памяти, связанной с пользовательским процессом и пейджинг(paging), выгрузка нечасто используемых страниц памяти. Solaris старается использовать пейджинг, если это возможно. Похоже, что если вы видите (vmstat w колонка), что идет своппинг, дело плохо совсем. 

Если freemem  меньше чем minfree, система немедленно свопирует процессы вместо пэйджинга. 

Solaris 8 uses a different algorithm for removing pages from memory. This new architecture is known as the cyclical page cache. It is designed to remove most of the file system cache-induced problems with virtual memory. The new system fills the same need as priority paging does for Solaris 2.5.1-7.

The cyclical page cache uses a file system free list to cache filesystem data only. Other memory objects are managed on a separate free list. (This second list would include application binaries, shared libraries, applications and uninitialized application data.)

Commands for monitoring swap space use

Размер процесса (Process size), см. также procmem.sh

/usr/ucb/ps alx, fields SZ or SIZE, /usr/proc/bin/pmap

Активность swap устройств

Узнаем для начале, где располагаются все swap области:

swap -l
swapfile             dev  swaplo blocks   free
/dev/dsk/c0t0d0s1   32,1      16 2097392 2097392  

Теперь для них  можно просмотреть дисковую активность с помощью команды iostat -xPnce 5

prtswap 

Ссылки: The Solaris Memory System

A:  Документация говорит нам, о некотором интеллекте в Oracle, который сам решает, будет ли использоваться async IO или нет. Главное, что бы параметр DISC_ASYNC_IO был установлен в TRUE (это значение по умолчанию). 

Для поддержки async IO в Solaris поддерживается специальная библиотека KAIO. Попробуем несложный тест, опубликованный в SunWolrd еще в 1998 году. Мы будем пробовать его с сырым устройством (raw device) и файловой системой. 

Узнаем, подгружен ли дравер kaio

oracle@t34:/dsvolk>modinfo | grep kaio 
131 10323ec4 3d82 178 1 kaio (kernel Async I/O)
131 10323ec4 3d82 178 1 kaio (kernel Async I/O for 32 bit com)

Есть, все нормально. Проверяем с сырым устройством:

truss -t kaio,lwp_create aio /dev/rdsk/c0t1d0s3
kaio(5, 0xFFFFFFE8, 0xFFFFFFFF, 0xFF21FB68, 0xFF210000, 0x00000000, 0xFF3E6158) = 0
lwp_create(0xFFBEF518, 0, 0xFF21FF5C) = 2
lwp_create() (returning as new lwp ...) = 0
kaio(AIOREAD, 3, 0xFFBEF898, 1024, 0, 0xFFBEFC98) = 0
kaio(AIOWAIT, 0x00000000) = 4290706584
aio succeeded                  <------------------------ Все в порядке. 

Проверяем с файловой системой. Здесь результат иной (и не зависит от того используется ли флаг directIO или нет):

oracle@t34:/dsvolk>truss -t kaio,lwp_create aio /opt/oracle/ora81/bin/oracleO 
kaio(5, 0xFFFFFFE8, 0xFFFFFFFF, 0xFF21FB68, 0xFF210000, 0x00000000, 0xFF3E6158) = 0
lwp_create(0xFFBEF520, 0, 0xFF21FF5C) = 2
lwp_create() (returning as new lwp ...) = 0
kaio(AIOREAD, 3, 0xFFBEF8A0, 1024, 0, 0xFFBEFCA0) Err#48 ENOTSUP             <------------------- Ошибка
lwp_create(0xFFBEF4C0, 0, 0xFF20DF5C) = 3
lwp_create() (returning as new lwp ...) = 0
lwp_create(0xFFBEF4C0, 0, 0xFF1FBF5C) = 4
lwp_create() (returning as new lwp ...) = 0
lwp_create(0xFFBEF4C0, 0, 0xFF1E9F5C) = 5
lwp_create() (returning as new lwp ...) = 0
lwp_create(0xFFBEF4C0, 0, 0xFF1D7F5C) = 6
lwp_create() (returning as new lwp ...) = 0
lwp_create(0xFFBEF4C0, 0, 0xFF1C5F5C) = 7
lwp_create() (returning as new lwp ...) = 0
lwp_create(0xFFBEF4C0, 0, 0xFF1B3F5C) = 8
lwp_create() (returning as new lwp ...) = 0
lwp_create(0xFFBEF4C0, 0, 0xFF1A1F5C) = 9
lwp_create() (returning as new lwp ...) = 0
lwp_create(0xFFBEF4C0, 0, 0xFF18FF5C) = 10
lwp_create() (returning as new lwp ...) = 0
lwp_create(0xFFBEF4C0, 0, 0xFF17DF5C) = 11
lwp_create() (returning as new lwp ...) = 0
kaio(AIOWAIT, 0x00000000) = 1
kaio(AIONOTIFY, -13074432) = 0

Мы видим, что идет большое число вызовов lwp_create, я думаю это эмулируется асинхронный ввод - вывод.  Не слишком эффективно, не правда ли ?

Ну хорошо, с Solaris более менее понятно, перейдем к Oracle. Я создал на моем сыром устройстве табличное пространство и табличку fall_source as select * from all_source. Перегружаю host. Затем захожу в sqlplus.  Делаю запрос select * from аall_source where rownum < 100. В соседнем окошке трассирую серверный процесс 

truss -p 605 

open64("/dev/rdsk/c0t1d0s3", O_RDWR|O_DSYNC) = 9           <---------- Открываем файл
getrlimit(RLIMIT_NOFILE, 0xFFBE6C98) = 0
fstat64(409, 0xFFBE6C00) = 0
fstat64(408, 0xFFBE6C00) Err#9 EBADF
fcntl(9, F_DUP2FD, 0x00000198) = 408                                  <------ Дублируем дескриптор
close(9) = 0
fcntl(408, F_SETFD, 0x00000001) = 0
ioctl(408, 0x0403, 0xFFBE6C5C) = 0
pread64(408, "1002\0\002 @\0\t\00295BE".., 8192, 73728) = 8192         <---- Читаем файл
pread64(408, "0602\0\002 @\0\n\00293 9".., 57344, 81920) = 57344

Что мы видим ? Нет вызовов kaio. Нету. Pread64 есть. А параметр disc_async_io стоит в true. Чем дальше, тем интереснее. Если в сессии сделать операцию типа create table as select то... появляются вызовы kaio. . 

Положение. как всегда спас Steve Adams. Именно он пояснил, что вызовы KAIO используются только для direct операций. В данном случае скорее всего были  direct reads - это чтение блока(ов) в PGA минуя SGA. Но если моя сортировка попадет на диск, в temp tablespace, а оно у меня лежит на файловой системе, то пойдет эмуляция async IO, а как это работает показано выше. 

Печальный итог. Включение асинхронного вывода имеет смысл только для БД, который целиком лежат на сырых устройствах или VxFS. Существенного выигрыша перенос отдельных файлов данных на сырые устройства не даст, чтение все рано синхронное. Да, выигрыш на  дисковых сортировках, но велик ли их  процент ?

Можно ли управлять интеллектом Oracle ? Можно, и  Стив Адамс показывает как именно лучше всего это сделать, используя параметр _filesystemio_options. До проведения экспериментов я не понимал его рекомендации установки данного параметра в directio. Теперь, как мне кажется, понимаю.

Вы спросите, а как же LGWR и DBWR ? Еще не успел проверить, что твориться в них. Но обязательно проверю.