16.01.2007 18:38
Цитата:
3 SUPERMAG.SMDOCUMENTS TABLE ACCESS [FULL]
27 SUPERMAG.SMSPEC TABLE ACCESS [FULL]
чего ж ты хочешь... оптимайзера по параметрам послушался? Индексы удешевил? db_file_multiblock_read_count не слишком задрал? Да, надо было в оракловую и там поднимать. Но теперь уж тут добьем твои вопросы.

по поводу 5. - это задаетcя при создании базы, сомневаюсь, что без пересодания контрольников это можно изменить.
17.01.2007 08:21
Да, оптимайзера послушался. Он мне выдает только два серьезных предупреждения.
1. OLEGON-WARNING: shared_pool_size=159383552,рекомендуется равным или менее 150000000
Насколько я понял, я сделал этот shared_pool_size немного больше, чем надо. Ну и пусть больше, памяти свободной еще вагон....
2. OLEGON-WARNING: Не рекомендуется использование автоматическое пополнение ассортиментов
Это я вообще не понял о чем. Я вроде нигде это пополнение не ставил.
3. OLEGON-WARNING: Рекомендуется не менее 10 redo-log групп
Ну у меня их 5, больше сделать не могу.

Еще после оптимизации пишет в консоли
OLEGON-WARNING: Не удалось выполнить alter database close immediate:ORA-01093: A
LTER DATABASE CLOSE only permitted with no sessions connected
В лог это не заносит. Но я так понял, что просто надо базу рестартовать и все будет ОК.
Больше по оптимайзеру у меня ошибок нет.

Теперь насчет индексов. Я не знаю, как их удешевить . Ну или так, как их удорожать? Все по умолчанию стоит, если надо переделать - только скажи куда, переделаю.

db_file_multiblock_read_count = 32, по совету оптимайзера.

Теперь по таблицам, которые SMSPEC и прочие. Когда в базе сидит куча юзеров, когда проц занят на 90-100%, то результаты вот такие.
SQL> set timing on
SQL> SELECT /*+ full(f)*/ count(*) from SMSPEC f;

COUNT(*)
----------
3310607

Затрач.время: 00:00:21.01
эта цифра колеблется от 00:00:1.02 до 00:00:24.04

SQL> set timing on
SQL> SELECT /*+ full(f)*/ count(*) from ffmaprep f;

COUNT(*)
----------
1402281

Затрач.время: 00:00:10.05

А когда никого в базе нет, то

SQL> set timing on
SQL> SELECT /*+ full(f)*/ count(*) from ffmaprep f;

COUNT(*)
----------
1402281

Затрач.время: 00:00:00.04

Это что значит? Что индексы все-таки нормальные? Или куда копать?

Олегон, ты мне посоветуй, пожалуйста, что делать то конкретно? Ну тупит машина при проведении документов и при проставлении цен неимоверно. 12-20 минут на накладную - нереальные тормоза, раньше минуты не было.
Просто не совсем понятно, в каком направлении копать. Перед тем, как ставить оракл, я форматнул винты, поставил win2003 srv standart sp1, накатил патчи, винду и оракл разнес по разным scsi дискам, на машине ничего больше нету, кроме кассового сервера, который работает достаточно редко, и папки для касс лежат не на тех дисках, где оракл и базы. Чтобы с ораклом все нормально было - я даже ставил его не сам, а спецов вызвал. И базу мне они тоже экспортировали / импортировали и настраивали. Блин, раньше винда, оракл, базы и кассовый сервер лежали на 1 диске и все быстрее работало....
Я тут уже и гипертрединг включал / выключал - не помогло, заметного эффекта нет.
Думал, что может проблемы с сетью - нифига, на сервере запускаю супермаг локально - та же картина.
Откатывался на старую версию супермага и оракл 8, там нет такого косяка с проведением документов и заполнение ценами последнего прихода. Но я не хочу оставаться на 8-ке, из-за "невозможно выделить 4096 байт разделяемой памяти"....
17.01.2007 08:48
У меня были похожие тормоза при проведенн документов(независимо сколько позиций).
Посмотри много ли у тебя асортиментов товара и если стоят галочки автоматическое пополненме то снимиих.
17.01.2007 09:35
Ассортиментов много.
Упс. Действительно стояли галочки "автоматическое пополнение" на нескольких неиспользуемых ассортиментах. убрал галочки - скорость проведения документов резко возросла. Спасибо!
Остались только проблемы с расчетом себестоимости и с заполнение ценами последнего прихода и пр.
17.01.2007 10:37
Цитата:
sevushka ......
2. OLEGON-WARNING: Не рекомендуется использование автоматическое пополнение ассортиментов
Это я вообще не понял о чем. Я вроде нигде это пополнение не ставил.
.....
Вот оптимизер говорит про эти галочки...
17.01.2007 12:42
А винты как формачены?? Размер кластера какой?


И ещё у меня возник такой вопрос, если HT включать не желательно, то как у Оракла 9 с двухядерностью процов?? Быстрее будет работать или тоже есть подводные камни???
17.01.2007 12:48
Винты - NTFS, кластер 8192 (8k). блок в оракле тоже 8192 (8k).
17.01.2007 12:54
Размер базы? Индексы в отдельном табличном пространстве? RAID какой? Винты тестил?
17.01.2007 13:04
База - 15 гиг, дамп занимает 680 метров. Индексы в отдельном пространстве, но файлы физически на том же диске, что и остальные. Рейд выключил вообще. Винты тестил, что linear read/write, что average seek графики стабильные, бэдов нет.

Блин, на этой же тачке, на этих же винтах эта же база, только оракл 8, просто летала . Правда раз в неделю стабильно "невозможно выделить 4096 байт памяти..." и приходится рестартовать оракл....
17.01.2007 13:09
А с расчётом с/с какие проблемы? Просто долго считает или на чём-то тормозит?
Часовой пояс GMT +3, время: 16:35.

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