Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

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

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

25 сообщений из 35, страница 1 из 2

все

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32040105

Alex Marmuzevich

Участник

Сообщения: 95

Рейтинг: 0 / 0

Поставил свежескачанный с Oracle дистр на RH7.3 (поставленный как серверная установка. Никаких лишних настроек). Все вроде нормально, только при инсталяции ругнулся на невозможность компиляции ins_ctx.mk (кто-нибудь знает почему?) + при создании репозитория выскочило сообщение о ошибке связанной с невозможностью доступа к shared memory (кто-нибудь знает почему?)
Сервер выключил. Утром включил. Запустил Oracle (dbstart), запустил listener (lsnrctl start listener). Пытаюсь подключиться с Win клиента и получаю по мозгам:
Unable to connect:
SQLState=08004
[Oracle][ODBC]ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux Error: 2: No such file or directory
На самом сервере пытался законнектится и снова получил, что shared memory realm does not exist. + что-то с юзверями не то. Чувствую, что проблема чайниковская, но не понимаю, как быть. Кто поможет?

...

Рейтинг:

0 / 0

31.07.2002, 20:25:04

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32042903

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

>выскочило сообщение о ошибке связанной с
>невозможностью доступа к shared memory (кто-нибудь
>знает почему?)

Во-первых из твоего постинга непонятно - стартует ли инстанс и выделяется ли shared memory. Судя по сообщению об ошибке - не выделяется. Проверять через клиента - не лучший способ. Попробуй так:

Код: plaintext

1.
2.
3.
4.
5.

[mylinux:~] $ sqlplus /nolog
SQL>conn internal
...
SQL>startup
...

Если sga не выделяется возможно проблема в установках shared memory на линухе.
Должно быть, что-то типа

Код: plaintext

[mylinux:~] # sysctl -a |grep shmmax
kernel.shmmax =  2147483647

почитай руководсво по инсталляции оракла на линухе как это сделать. Ну и планируемая sga не должна быть больше чем возможности по выделению shared memory.

Если sga все же выделилась, то сделай шатдаун оракла и проверь освободилась ли она:
[mylinux:~] # ipcs -a

Вообще при такого рода проблеме на 8i помогает инсталляция оракловского патча для линуха. Ну а для 9-ки такого не знаю.

...

Рейтинг:

0 / 0

13.08.2002, 15:06:55

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32042968

Lazy

Гость

Не подскажешь что это за патч такой.
Я тут попробовал для 8.0.5(RH6.2) дать ~500 mb - не может ORA-27123: unable to attach to shared memory segment
причем ipcs -l : shmmax(kb) = 2097151, а kernel.shmmax = 4294967295 (в чем прикол так и не понял). Причем что для 2.2 ядра,что для 2.4 ситуация не меняется. Второй день бьюсь, мысли уже исчерпаны ;((

...

Рейтинг:

0 / 0

13.08.2002, 18:03:18

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32042985

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

для 8.0 посмотри вот тут . Называется glibcpatch.tgz

А сколько физической памяти на сервере? Должно быть больше примерно на 30-40% (конечно зависит от потребностей других приложений), чем sga, которую ты планируешь выделить. Может в этом проблема? Пересчитай параметры.

>причем ipcs -l : shmmax(kb) = 2097151, а kernel.shmmax =
>4294967295 (в чем прикол так и не понял)

фиг его знает - у меня тоже так :-)

...

Рейтинг:

0 / 0

13.08.2002, 18:44:23

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32042999

Lazy

Гость

Да, этот патч у меня стоит, спасибо.
В том-то и дело что памяти 4Гб и все свободно.Единственное что свап у меня 2000Мб, но это несравнимо больше 500мб. Грустно :-)).

...

Рейтинг:

0 / 0

13.08.2002, 19:38:34

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043005

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

>В том-то и дело что памяти 4Гб и все
>свободно.Единственное что свап у меня 2000Мб, но это
>несравнимо больше 500мб. Грустно :-)).

да, странно :-( . Кстате, своп вообще роли не играет, т.к. shared memory не свопится. Может все таки ошибка в параметрах, т.е. пересчитай сколько получится:((db_block_buffers * block size) + (shared_pool_size + large_pool_size + log_buffers) + 1MB

ну, еще посмотри
$ ulimit -a

может просто с физ. памятью проблемы?

больше ничего в голову не приходит :-(

...

Рейтинг:

0 / 0

13.08.2002, 20:07:09

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043013

Lazy

Гость

Опытным ( :-)) путем нашел что ровно 512М shm еще размещает,а больше уже нет. Я же говорю - грустно :-((.
У тебя какие версии и сколько давал под SGA?

/root]# su - dbinstall -c 'ulimit -a'
core file size (blocks) 1000000
data seg size (kbytes) unlimited
file size (blocks) unlimited
max memory size (kbytes) unlimited
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 29695
pipe size (512 bytes) 8
open files 16384
virtual memory (kbytes) 2105343
---------------------
при
db_block_size = 4096
db_block_buffers = 106862

SVRMGR> ORACLE instance started.
Total System Global Area 536231184 bytes
Fixed Size 48400 bytes
Variable Size 97943552 bytes
Database Buffers 437706752 bytes
Redo Buffers 532480 bytesbytesDatabase mounted.
Database opened.

[root@newserver pfile]# ipcs -u
------ Shared Memory Status --------
segments allocated 1
pages allocated 131072 !!!!!!!!!!!!!!!!!!!!!!!!!!!!
pages resident 7685
---------------------------
при
db_block_size = 4096
db_block_buffers = 106863

SVRMGR> ORA-27123: unable to attach to shared memory segment
Linux Error: 22: Invalid argument
------------------------

...

Рейтинг:

0 / 0

13.08.2002, 21:53:44

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043094

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

2Lazy

посмотри как нужно сдвигать начальный адрес SGA в Administration Guide 8.1.7 for Linux. Не уверен что есть такая возможность для 8.0.x Если без извращений, то на Linux макс. раздел. память будет ограничена примерно 730М
А зачем тебе SGA больше 500М ? Быстрее от этого Oracle работать не станет. Тем более 8.0

...

Рейтинг:

0 / 0

14.08.2002, 11:21:46

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043227

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

>Опытным ( :-)) путем нашел что ровно 512М shm еще
>размещает,а больше уже нет. Я же говорю - грустно :-((.
>У тебя какие версии и сколько давал под SGA?

версии у меня немного другие:
Оракл везде 8.1.7.2,

а платформы (это с которыми можно играться)
RH 6.2 - 2.2.14-5.0 - phys. mem. 512Mb
SuSE 7.3 - 2.4.4-4GB - phys. mem. 1Gb

ну и еще там разные Linux, Tru64 v.5.1, HP-UX 11.00, с которыми играться нельзя :-(

Так вот на первых двух я давал размер sga больше, чем физ. память (shmmax у меня везде с запасом) и оракл стартует, shared memory выделяется. Более того, делаю фуллсканы больших таблиц, для того чтоб заполнить кеш и тоже работает без свопа. И куда оно девается?

ulimit у меня примерно такие же.

>посмотри как нужно сдвигать начальный адрес SGA в
>administration Guide 8.1.7 for Linux. Не уверен что есть
>такая возможность для 8.0.x

есть такая возможность - подробно описана на металинке в Note 1028623.6. Правда для солярки, но я бы на твоем месте попробовал.

>Если без извращений, то на
>Linux макс. раздел. память будет ограничена примерно
>730М

откуда дровишки?

>А зачем тебе SGA больше 500М ? Быстрее от этого Oracle
>работать не станет. Тем более 8.0

Вот это новость! Неужели кеширование блоков не имеет всемирно-исторического значения? Тем более на 8.0 :-))

...

Рейтинг:

0 / 0

14.08.2002, 16:18:41

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043352

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

>есть такая возможность - подробно описана на
>металинке в Note 1028623.6. Правда для солярки, но я бы
>на твоем месте попробовал.

Вот тут еще на досуге порылся в интернете и нашел вот такую мысль, что перед тем как сдвигать sga, надо проверить параметры ядра:

:~] # grep RANGE /usr/src/linux-2.2.14/include/asm-i386/shmparam.h
#define SHM_RANGE_START 0x50000000
#define SHM_RANGE_END 0x60000000

а затем проверь где у тебя начинается (должна начинаться) sga:

:~] $ genksms|head -1
.set sgabeg,0X50000000

Вот у меня на RH 6.2 вот так, как выше.

...

Рейтинг:

0 / 0

14.08.2002, 21:15:26

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043356

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

Хм... продолжаем разговор (я никого не разбудил?:-))

Так вот, как показали последние исследования советских ученых на металинке, существует специально подготовленная ораклом утилита для тренировки на шаред мемори:

oracle] $ tstshm
Number of segments gotten by shmget() = 50
Number of segments attached by shmat() = 50
Segments attach at higher addresses
Default shared memory address = 0x406b6000
Lowest shared memory address = 0x406b6000
Highest shared memory address = 0x46ab6000
Total shared memory range = 106954752
Total shared memory attached = 104857600
Largest single segment size = 2097152
Segment boundaries (SHMLBA) = 4096 (0x1000)

а можно также употреблять как

tstshm -t<size of SGA> -b<new attach address>

Почему я получаю все время новые адреса я так и не понял :-(

Ладно, пошел спать ...

...

Рейтинг:

0 / 0

14.08.2002, 23:06:05

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043382

Animal

Участник

Сообщения: 503

Рейтинг: 0 / 0

У меня такие же грабли на Oracle9.2 под W2K. Как только устанавливаешь какое-либо значение DB_BLOCK_BUFFERS все крантец, память не выделяется. Убираешь этот параметр - экземпляр нормально работает.

...

Рейтинг:

0 / 0

15.08.2002, 05:00:35

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043439

Noname

Гость

2Animal:
Из Oracle9i Database Reference:
DB_BLOCK_BUFFERS
Note: This parameter is deprecated in favor of the DB_CACHE_
SIZE parameter. Oracle recommends that you use DB_CACHE_
SIZE instead. Also, DB_BLOCK_BUFFERS cannot be combined with the new dynamic DB_CACHE_SIZE parameter; combining these parameters in the same parameter file will produce an error. DB_BLOCK_BUFFERS is retained for backward compatibility.

...

Рейтинг:

0 / 0

15.08.2002, 10:58:23

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043698

Lazy

Гость

Спасибо всем. Решилось.
Сдвинул sgabeg на 0х70000000 и oracle стал понимать SGA> 1Гб, правда не без приколов. Подробно не тестировал, но где-то в районе 1.3 Гб Oracle стартует ,но потом не может shutdown - говорит что его нету,хотя все процессы висят(ORA-01034: ORACLE not available).Может я переборщил со сдвигом.
Я тоже слышал про ~730(780)Мб. Потому и не пытался сдвигать, полагая что проблемы в чем-то другом. Возможно, я забыл упомянуть самое главное - у меня 8.0.5SE.

2killed:
>А зачем тебе SGA больше 500М ? Быстрее от этого Oracle работать не станет. Тем более 8.0
сейчас SGA>500Mb, наверное, ненужно. Смысл в том что если понадобится, то чтобы была возможность сделать. Тем более, что пока есть время пробовать.

2.dba:
Ссылку не нашел, но есть мнение, что при нормально загруженном сервере, данные которые нужны реже чем раз в 8-10мин должны читаться с диска. В любом случае бездумное кеширование блоков приводит к замедлению Oracle.
К metalink'u доступа к сожалению нету. А описания этих tstshm,genksms,наверное, больше нигде не найти.
>Так вот на первых двух я давал размер sga больше, чем физ. память (shmmax у меня везде с запасом) и оракл
>стартует, shared memory выделяется. Более того, делаю фуллсканы больших таблиц, для того чтоб заполнить кеш
>и тоже работает без свопа. И куда оно девается?
странно, у меня говорит out of memory

Кстати tstshm выдавал интересные рез-ты(это до сдвига):
-----------------------------------------------
root]# tstshm
Number of segments gotten by shmget() = 50
Number of segments attached by shmat() = 50
Segments attach at higher addresses
Default shared memory address = 0x404c7000
Lowest shared memory address = 0x404c7000
Highest shared memory address = 0xbfec7000
Total shared memory range = 2143289344
Total shared memory attached = 104857600
Largest single segment size = 2097152
Segment boundaries (SHMLBA) = 4096 (0x1000)

root]# tstshm -s100000000 -t50000000
size = 100 000 000
totsize = 50 000 000
Succeeded in attaching 48 segments with total shm of 50000000

root]# tstshm -s100000000 -t500000000
size = 100 000 000
totsize = 500 000 000
Shmat error: Identifier removed
shmctl: Identifier removed

[root@newserver /root]# tstshm -s100000000
size = 100000000
Number of segments gotten by shmget() = 50
Number of segments attached by shmat() = 21
Segments attach at higher addresses
Maximum size segments are not attached contiguously!
Segment separation = 100003840 bytes
Default shared memory address = 0x404c7000
Lowest shared memory address = 0x404c7000
Highest shared memory address = 0xbd792000
Total shared memory range = 2200080640
Total shared memory attached = 2100 000 000
Largest single segment size = 100000000
Segment boundaries (SHMLBA) = 4096 (0x1000)
--------------------------------------------
а genksms и сейчас выдает
# genksms|head -1
.set sgabeg,0X20000000
а это и есть 512М
--------------------------------------------

...

Рейтинг:

0 / 0

15.08.2002, 18:39:19

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043730

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

>2.dba:
>Ссылку не нашел, но есть мнение, что при нормально
>загруженном сервере, данные которые нужны реже чем
>раз в 8-10мин должны читаться с диска.
>В любом случае
>бездумное кеширование блоков приводит к замедлению
>Oracle.

так ведь все в этом мире относительно :-). Если у тебя таблицы большие и приложение делает аналитические запросы, т.е. частые фулсканы, то почему бы их не закешировать? Конечно, если данные нужны относительно редко, а в промежутках они еще и интенсивно апдейтятся, то кеширование не только не поможет, но и затормозит, а если, наоборот, read-only, то очень даже поможет. Т.е. опять же все зависит от приложения.

>К metalink'u доступа к сожалению нету. А описания этих
>tstshm,genksms,наверное, больше нигде не найти.

да не очень там и написано. Только хорошо описан алгоритм при выделении сегментов шаред мемори (в смысле попытки выделить один или много (если много, то последвательные или нет)).

>Кстати tstshm выдавал интересные рез-ты(это до
>сдвига):

насколько я понимаю сдвиг (т.е. релинкование оракловских бинарников) не влияет на результаты работы tstshm. Она просто выполняет алгоритм выделения, так же как и оракловский executable и говорит будет ли выделение успешным. Можешь ее протрассировать линуховым strace'ом.

>а genksms и сейчас выдает
># genksms|head -1
>.set sgabeg,0X20000000
>а это и есть 512М

Ты ж делал новый ksms.s и с ним перелинковывал, а genksms показывает тебе дефолтный адрес (это я так думаю :-)

Чего я так и не понял - так это результатов работы tstshm без параметров. Все эти цифры нижнего и верхнего возможных адресов выглядят как-то отвлеченно и ни о чем не говорят.

...

Рейтинг:

0 / 0

15.08.2002, 22:25:33

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32043908

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

2.dba

Кэширование - оно ведь не бесплатно. Больший кэш - бОльшие затраты. Предполагаю, что Оракл активно меняет свои алгоритмы, чтобы идти в ногу со временем (дешевая память, бОльший объем).

Данные получаемые через Full Table Scan не кэшируются.
www.oradba.com.ru -> Optimizer -> Статья Тима Гормана

2Lazy
Прочел твое сообщение и понял, что немного соврал по прошествии времени. Когда я пробовал на RH6.2 сразу на сеежей инсталляции, то по дефолту я смог взять около 730М. После сдвига до 1.3Г
Так что данные совпадают :)

...

Рейтинг:

0 / 0

16.08.2002, 14:26:17

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32044037

Lazy

Гость

2.dba
>Чего я так и не понял - так это результатов работы tstshm без параметров. Все эти цифры нижнего и верхнего
>возможных адресов выглядят как-то отвлеченно и ни о чем не говорят.
Говорят-говорят, они примерно (:-)) показывают начало и конец диапазона. А вообще-то он глючит.

2killed
В том-то и дело, что без сдвига я мог взять только 512М, а после разных сдвигов максимум получился ~2,5 гб. Ядро 2.4, на 2.2 сейчас нет возможности посмотреть. Oracle запускается, простейшие запросы отрабатывают, детально не тестировал.
Так что данные не совпадают ;-).

...

Рейтинг:

0 / 0

16.08.2002, 18:23:04

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32044062

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

Перечитал снова твои постинги - цифры совпадают ;)
Теоретически действительно должно быть больше 1,3Г, но на практике я не видел чтобы это работало

...

Рейтинг:

0 / 0

16.08.2002, 22:26:55

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32044363

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

>Данные получаемые через Full Table Scan не кэшируются.
>www.oradba.com.ru -> Optimizer -> Статья Тима Гормана

Что значит не кешируются?

1. Кешируются, если буферный кеш свободен (т.е. выше hwm).
2. Кешируются, если таблица создана (или модифицирована) с ключевым словом cache.

...

Рейтинг:

0 / 0

19.08.2002, 19:05:53

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32044449

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

Ты вроде про большие таблицы говорил? А статью полностью прочитал?

Что означает первый пункт твоего постинга? Я не совсем понял как связано заполнение кэша и hwm кэша (хотя такого понятия у кэша нет) с табличным сканированием?

...

Рейтинг:

0 / 0

20.08.2002, 10:52:53

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32044571

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

>Ты вроде про большие таблицы говорил? А статью
>полностью прочитал?

если честно, то я еще не читал :-)

>Что означает первый пункт твоего постинга? Я не совсем
>понял как связано заполнение кэша и hwm кэша (хотя
>такого понятия у кэша нет) с табличным сканированием?

да, такого понятия нет, но я имел ввиду следующее:

select *
from v$bh
where status = 'free'

т.е. те буферы, которые не заполнялись со времени старта инстанса.

теперь, когда договорились о терминологии :-) проверяем:
исх. данные:
db_block_buffers = 10000
таблица с1_2 (7513 blocks, cache = yes)
таблица с1_2noc (7513 blocks, cache = no)

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

SQL> startup
ORACLE instance started.
 
Total System Global Area   190927008  bytes
Fixed Size                     73888  bytes
Variable Size              108400640  bytes
Database Buffers            81920000  bytes
Redo Buffers                  532480  bytes
Database mounted.
Database opened.
SQL> select count(*) from v$bh where status = 'free';
 
  COUNT(*)
 ----------
 
       9638

база тестовая, так что другой активности практически нет.

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.

SQL> select count(*) from c1_2noc;

  COUNT(*)
 ----------
 
    2476440 

Abgelaufen:  00 : 00 : 00 . 71 

Ausf³hrungsplan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 1141  Card= 1 )
    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'C1_2NOC' (Cost= 1141  Card= 2476440 
          )





Statistiken
 ----------------------------------------------------------
 
         195   recursive calls
          27   db block gets
        7545   consistent gets
        7513   physical reads
           0   redo size
         294   bytes sent via SQL*Net to client
         421   bytes received via SQL*Net from client
           2   SQL*Net roundtrips to/from client
           4   sorts (memory)
           0   sorts (disk)
           1   rows processed

SQL> /

  COUNT(*)
 ----------
 
    2476440 

Abgelaufen:  00 : 00 : 00 . 41 

Ausf³hrungsplan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 1141  Card= 1 )
    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'C1_2NOC' (Cost= 1141  Card= 2476440 
          )





Statistiken
 ----------------------------------------------------------
 
           0   recursive calls
          27   db block gets
        7521   consistent gets
           0   physical reads
           0   redo size
         294   bytes sent via SQL*Net to client
         421   bytes received via SQL*Net from client
           2   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
           1   rows processed

SQL> select count(*) from c1_2;

  COUNT(*)
 ----------
 
    2476440 

Abgelaufen:  00 : 00 : 00 . 61 

Ausf³hrungsplan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 1141  Card= 1 )
    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'C1_2' (Cost= 1141  Card= 2476440 )




Statistiken
 ----------------------------------------------------------
 
         195   recursive calls
           9   db block gets
        7537   consistent gets
        7514   physical reads
           0   redo size
         294   bytes sent via SQL*Net to client
         421   bytes received via SQL*Net from client
           2   SQL*Net roundtrips to/from client
           4   sorts (memory)
           0   sorts (disk)
           1   rows processed

SQL> select count(*) from c1_2;

  COUNT(*)
 ----------
 
    2476440 

Abgelaufen:  00 : 00 : 00 . 51 

Ausf³hrungsplan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 1141  Card= 1 )
    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'C1_2' (Cost= 1141  Card= 2476440 )




Statistiken
 ----------------------------------------------------------
 
           0   recursive calls
           9   db block gets
        7513   consistent gets
           0   physical reads
           0   redo size
         294   bytes sent via SQL*Net to client
         421   bytes received via SQL*Net from client
           2   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
           1   rows processed

обрати внимание на physical reads

...

Рейтинг:

0 / 0

20.08.2002, 13:52:53

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32044631

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

Очень интересно! Я так понимаю эти результаты получены на 9ке или же просто эффект чистого кэша???
Ниже результаты с 8.1.7 (работающая база - кэш заполнен)

Код: plaintext

SQL> select count(*) from sys.source$;

  COUNT(*)
 ----------
 
     199103 


Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE
    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'SOURCE




Statistics
 ----------------------------------------------------------
 
          18   recursive calls
          10   db block gets
        1065   consistent gets
        1062   physical reads
           0   redo size
         294   bytes sent via SQL*Net to client
         308   bytes received via SQL*Net from client
           3   SQL*Net roundtrips to/from client
           2   sorts (memory)
           0   sorts (disk)
           1   rows processed

SQL> /

  COUNT(*)
 ----------
 
     199103 


Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE
    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'SOURCE




Statistics
 ----------------------------------------------------------
 
           0   recursive calls
          10   db block gets
        1061   consistent gets
        1061   physical reads
           0   redo size
         294   bytes sent via SQL*Net to client
         308   bytes received via SQL*Net from client
           3   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
           1   rows processed






Statistics
 ----------------------------------------------------------
 
           0   recursive calls
          10   db block gets
        1061   consistent gets
        1061   physical reads
           0   redo size
         294   bytes sent via SQL*Net to client
         308   bytes received via SQL*Net from client
           3   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
           1   rows processed






Statistics
 ----------------------------------------------------------
 
          18   recursive calls
          10   db block gets
        1065   consistent gets
        1062   physical reads
           0   redo size
         294   bytes sent via SQL*Net to client
         308   bytes received via SQL*Net from client
           3   SQL*Net roundtrips to/from client
           2   sorts (memory)
           0   sorts (disk)
           1   rows processed

SQL> /

  COUNT(*)
 ----------
 
     199103 


Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE
    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'SOURCE




Statistics
 ----------------------------------------------------------
 
           0   recursive calls
          10   db block gets
        1061   consistent gets
        1061   physical reads
           0   redo size
         294   bytes sent via SQL*Net to client
         308   bytes received via SQL*Net from client
           3   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
           1   rows processed






Statistics
 ----------------------------------------------------------
 
           0   recursive calls
          10   db block gets
        1061   consistent gets
        1061   physical reads
           0   redo size
         294   bytes sent via SQL*Net to client
         308   bytes received via SQL*Net from client
           3   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
           1   rows processed

Я попробовал также на 9.2 только что стартованном экземпляре. Если не ошибся, то при незаполненном кэше Оракл просекает эту ситуацию и кэширует таблицу. Вот пример, когда была свободна 1000 блоков

Код: plaintext

SQL> select count(*) from t3;

  COUNT(*)
 ----------
 
      73250 


Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 277  Card= 1 )
    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'T3' (Cost= 277  Card= 73250 )




Statistics
 ----------------------------------------------------------
 
         214   recursive calls
           0   db block gets
        2883   consistent gets
        2817   physical reads
           0   redo size
         305   bytes sent via SQL*Net to client
         491   bytes received via SQL*Net from client
           2   SQL*Net roundtrips to/from client
           4   sorts (memory)
           0   sorts (disk)
           1   rows processed

SQL> /

  COUNT(*)
 ----------
 
      73250 


Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 277  Card= 1 )
    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'T3' (Cost= 277  Card= 73250 )




Statistics
 ----------------------------------------------------------
 
           0   recursive calls
           0   db block gets
        2852   consistent gets
        1817   physical reads
           0   redo size
         305   bytes sent via SQL*Net to client
         491   bytes received via SQL*Net from client
           2   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
           1   rows processed

Опять же боюсь ошибиться, проверял на скорую руку. Но выводы у меня получаются такие: Если кэш пустой - экземпляр стартован недавно, то все блоки при сканировании таблицы будут кэшироваться по максимуму. Если кэш заполнен (а это есть специфика кэша по определению), то будет работать старый алгоритм и блоки таблицы не будут кэшироваться при FTS. По идее очень логично: если есть свободные блоки - зачем им "пропадать зазря", однако если свободных блоков нет, то вытеснять их мы не будем, поскольку вероятность повторного использования блоков, считываемых при полном таб. сканировании мала.

...

Рейтинг:

0 / 0

20.08.2002, 15:41:47

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32044648

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

>Но выводы у меня получаются такие: Если кэш пустой -
>экземпляр стартован недавно, то все блоки при
>сканировании таблицы будут кэшироваться по
>максимуму. Если кэш заполнен (а это есть специфика
>кэша по определению), то будет работать старый
>алгоритм и блоки таблицы не будут кэшироваться при
>FTS. По идее очень логично: если есть свободные блоки -
>зачем им "пропадать зазря", однако если свободных
>блоков нет, то вытеснять их мы не будем, поскольку
>вероятность повторного использования блоков,
>считываемых при полном таб. сканировании мала

Да, именно так. Только одно дополнение - если таблица создана (или модифицирована) с ключевым словом cache, то она вытеснит из кеша любые другие таблицы (даже те которые с cache = yes)

не люблю я новые версии :-). У меня везде 8.1.7.2, а 9-ки даже для теста нет. Вот все собираюсь заинсталлить :-)

...

Рейтинг:

0 / 0

20.08.2002, 16:07:42

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32044658

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

атрибут CASH будет работать только для таблиц размером меньше чем CACHE_SIZE_THRESHOLD. Для остальных он игнорируется

...

Рейтинг:

0 / 0

20.08.2002, 16:25:33

| Ответить | Цитировать | Написать

Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

#32044664

.dba

Участник

Откуда: Киев->Мюнхен

Сообщения: 2 289

Рейтинг: 0 / 0

>атрибут CASH будет работать только для таблиц
>размером меньше чем CACHE_SIZE_THRESHOLD. Для
>остальных он игнорируется

так это ж пережиток капитализма (т.е. 8.0 версии) - на 8.1.7 такого параметра нет.

...

Рейтинг:

0 / 0

20.08.2002, 16:44:36

| Ответить | Цитировать | Написать

25 сообщений из 35, страница 1 из 2

все

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Oracle 9.0.2i & RedHat 7.3 &... shared memory realm does not exist

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=52&fpage=2765&tid=1990009]:	0ms
get settings:	6ms
get forum list:	10ms
check forum access:	2ms
check topic access:	2ms
track hit:	50ms
get topic data:	8ms
get forum data:	2ms
get page messages:	180ms
get tp. blocked users:	2ms
others:	195ms

total:	457ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы