08.08.2006 17:24
kadr
 
Цитата:
RKuzmin Эх все бы Вам графические утилитки. Джаву тормозную и т.п. :))
Выкачивать спотлайт, устанавливать, потом он еще сам жрет ресурсов немеренно.
Ведь все можно сделать с помощью простых скриптиков.
Так выложи, делом бы помог, а не кидался фразами о том, что кошернее, а что нет
09.08.2006 05:55
Andy
 
Утром на след день пришел - провел чистый эксперимент - полез в отбор каточек по поставщику и месту хранения - SHARED_POOL !!!
Бац !
видимо удаление и создание индексов не помогло.
OlegON а что еще можно сделать - может престройку таблицы я неправильно понял ? еще что то надо сделать ?
09.08.2006 06:01
Andy
 
удалил индекс по SMSPEC_ART.
И все равно этот запрос приводит к нехватке места в shared_pool
09.08.2006 07:01
Mtirt
 
Зачем? Тебе выше писали, не надо удалять ИНДЕКСЫ !!!
Лучше разберись, почему так происходит. Может имеет смысл поменять параметры базы?
Выложи здесь параметры базы и pfile.
Укажи количество одновременно работающих пользователей.
Специалисты по ораклу тебе может что хорошего посоветуют.

И еще, ну не пользуйся ты этим фильтром, он вешает все намертво.
Если надо отобрать товар, поставляемый поставщиком - сделай отбор в приходных накладных по поставщику и месту хранения и отбери товары из накладных. Работает очень быстро.
09.08.2006 07:22
OlegON
 
Цитата:
Mtirt И еще, ну не пользуйся ты этим фильтром, он вешает все намертво.
Не только вешает, но в некоторых случаях опять роняет индекс. Так что действительно, лучше им не пользоваться.
09.08.2006 07:38
Andy
 
Mtirt,
удаляю индексы по рекомендации OlegOna - "Проблема решается поиском таблицы, на которой встают запросы и ее перестройкой с полным убиением и созданием индексов"
не помогает, вот какие параметры базы:
оперативы гиг, размер после увеличение INDX и USERS около 12 гиг,
юзеров одновременно скажем максимально 15 (помимо клиентов супермага есть свои проги для получения отчетиков)
db_files = 1024
open_cursors = 100
max_enabled_roles = 30
db_file_multiblock_read_count = 8
db_block_buffers = 30600
shared_pool_size = 250746496
large_pool_size = 614400
java_pool_size = 0
job_queue_processes = 3
job_queue_interval = 60
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
processes = 150
parallel_max_servers = 5
log_buffer = 32768
max_dump_file_size = 10240
global_names = true
db_block_size = 8192
distributed_transactions = 10
compatible = 8.1.0
sort_area_size = 4096000
sort_area_retained_size = 4096000
09.08.2006 08:15
Mtirt
 
Цитата:
olegon
Цитата:
Mtirt И еще, ну не пользуйся ты этим фильтром, он вешает все намертво.
Не только вешает, но в некоторых случаях опять роняет индекс. Так что действительно, лучше им не пользоваться.
Каким образом ты выясняешь, что индекс упал? Not valid или еще что?
09.08.2006 08:47
Andy
 
мне кажеться индекс тут не всегда причем.
Я вообще удалил этот индекс который в запросе указан явно подсказкой /*+INDEX(SMSPEC_ART) а ошибка все равно остается
09.08.2006 08:50
OlegON
 
Цитата:
Mtirt Каким образом ты выясняешь, что индекс упал? Not valid или еще что?
Методом исключения :) Никаких not valid, как я и говорил, не появляется. Просто он перестает вдруг использоваться. Причем shared_pool начинает стремительно заполняться и валится по banima buffer какой-то ошибке, нехватка места. Сейчас уже и не вспомню точно. Убиваешь, создаешь индекс, все работает дальше. В свое время на металинке искал, ничего не нашел, да и у преподов спрашивал, не ясно. Похоже на Оракловый глюк. Приведете ошибку - поищу еще раз.
14.09.2006 00:08
vdm
 
Оно добралось и до нас.
Как и у Andy, через год работы базы *09

Кассовый модуль выдал (сокращено):

[SMLibrary]:Ошибка при создании объекта в базе данных. Запись 5. Код=80004005h (0) [Microsoft OLE DB Provider for Oracle]:Oracle error occurred, but error message could not be retrieved from Oracle. Запись 6. Код=80004005h (0) [SmLibaryBase trace]:insert into Supermag.TTOnlineCheck

Далее

Код=80004005h (0) [Microsoft OLE DB Provider for Oracle]:ORA-04031: невозможно выделить 4096 байт разделяемой памяти ("shared pool","begin Supermag.Cash.NewOnlin...","PL/SQL MPCODE","BAMIMA: Bam Buffer") Запись 5. Код=80004005h (0) [Microsoft OLE DB Provider for Oracle]:Unspecified error Запись 6. Код=80004005h (0) [SmLibaryBase trace]:{ call Supermag.Cash.NewOnlineCheck } %7 %8

Ну и т.д.

optimizer сказал:

Не удалось выполнить analyze table "SUPERMAG"."SMCASHDISC" validate structure cascade:ORA-01499: table/index cross reference failure - see trace file

Только в этот момент ни трейса, ни в алертлоге ничего *22

Утром кассовый снова уронил базу по 'PL/SQL MPCODE","BAMIMA: Bam Buffer"', а в логе:
ORA-00600: код внутр. ошибки, аргументы: [1100], [198260768], [157787640], [], [], [], [], []
ORA-04031: невозможно выделить 4200 байт разделяемой памяти ("shared pool","unknown object","sga heap","state objects")

На SMCASHDISC один индекс SMCASHDISC_PK
Судя по всему нужно пересоздать.
Хотелось бы сделать это быстро и правильно (без бэкапа).

1) Какие нить ограничения на его drop могут помешать?

2) С какими параметрами создавать его?
TOAD-у верить ? *16
CREATE UNIQUE INDEX SUPERMAG.SMCASHDISC_PK
ON SUPERMAG.SMCASHDISC(LOCID, DESKNUM, ZNUM, CHECKNUM, ITEM, DISCKIND) PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE(
INITIAL 376832 K
NEXT 376832 K
MAXEXTENTS 4096
PCTINCREASE 0
FREELISTS 3
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
)
NOLOGGING TABLESPACE INDX
Часовой пояс GMT +3, время: 19:41.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.