Скорость копирования по сети. : Железо

off-top:
- доктор, меня все игнорируют
- следующий.

А если серъёзно, то всё же сообщи размеры окна перегрузки выставленные в реестре для использования под буфер-кэш верхней памяти, при активном росте данных, неправильной (неактуальной) статистике и др. факторах очень сильно проседает чтение из/в буферный кэш. Если же не использовать AWE, то изменения в производительности не будут так заметны.

Рекомендации от меня: не меняя настроек памяти, собрать статистику.

Тонкий офтоп. Не поняла. Сижу думаю - обижаться или нет. Если действительно интересно, что у меня в реестре, то напиши где это искать.

если есть возможность - скачай одну из последних версий программы эверест. Это коммерческое продолжение аиды. Там есть пробный период использования с какими-то ограничениями, но в целом картина будет более чёткой.

789654

b) добавить в реестр (HKLM\Software\Oracle\HomeX) ключ (тип – строковый параметр) размера AWE_WINDOW_MEMORY – окна, сквозь которое будут обрабатываться DB_BLOCK_BUFFERS, вынесенные в «верхнюю» память. Указывается в байтах. Если этот ключ не установлен явно, используется значение по умолчанию 1 гигабайт. Зачастую этот размер достаточен, однако вполне работоспособны и экземпляры с AWE_WINDOW_MEMORY = 0,5 гигабайт;
в версии 9.2.0 существует небольшое изменение по сравнению с предыдущими релизами - Oracle начал проверять минимальный размер окна AWE_WINDOW_MEMORY по формуле:

min(AWE_WINDOW_MEMORY) = (4096*DB_BLOCK_SIZE*_DB_BLOCK_LRU_LATCHES)/8
где значение по умолчанию _DB_BLOCK_LRU_LATCHES = (16*CPU_COUNT)

Рассчитанные минимумы AWE_WINDOW_MEMORY для популярных значений DB_BLOCK_SIZE и CPU_COUNT:

+---------------+-----------+-----------------------------+
| DB_BLOCK_SIZE | CPU_COUNT | MIN(AWE_WINDOW_MEMORY), Mb |
+---------------+-----------+-----------------------------+
8192 2 128
8192 4 256
8192 8 512
8192 16 1024
16384 2 256
16384 4 512
16384 8 1024
16384 16 2048
32768 2 512
32768 4 1024
32768 8 2048
32768 16 4096

взято здесь http://sql.ru/forum/actualthread.aspx?tid=208727&pg=1&hl=awe+%f0%e5%e5%f1%f2%f0

Прочитала обе ссылки. Я так поняла, что параметр влияет только на то, сколько памяти я могу взять под BUFFER CACHE. Если я поставлю больше 1Гб , то это решит мою проблему с винтами?

нормальный сервак, судя по конфигурации! У меня артикулов в базе меньше раза в три, но и комп слабее значительно и при этом тормазов нет заметных (особенно, после того как выгрузку базы по требованию зделал). Поэтому, как писалось выше, мыслю что нужно провести простую диагностику. Открываешь ПУСК - ПРОГРАММЫ - АДМИНИСТРИРОВАНИЕ - ПРОИЗВОДИТЕЛЬНОСТЬ. Удаляешь сразу счётчики по умолчанию и ставишь свои. Какие именно? Думаю, тебе подскажут более опытные админы. Я бы обратил внимание на счётчик ФИЗИЧЕСКИЙ ДИСК - ТЕКУЩАЯ ДЛИНА ОЧЕРЕДИ ДИСКА. можно поставить отдельно на каждый физический диск.. Счётчики на процессор поставь, оперативку посмотри тоже. Делаешь так. Останавливаешь все сервисы, запускаешь счётчики, потом стартуешь сервисы оракла и пробуешь что-нить поделат в базе. Если всё нормально - запускаешь ещё пользователей по одному и таким образом можно определить что именно грузит систему больше всего. Потом отписывешься о результатах и мегамыслители дают свои комментарии

Да, сразу включила такой счетчик. Зеленая линия дисков застыла на 100 процентах........ И за 2 часа не опустилась. На предложенный экперимент нужна санкция. Тут на 20 минут с базы выгнать всех - скандал. Спасибо на добром слове - буду копать. Нет это средняя скорость. Текущая не в линию, но тоже высоко.

смотри не на линии, а на циферки внизу. ТЕКУЩАЯ ДЛИНА ОЧЕРЕДИ ДИСКА - это сколько необработанных запросов у тебя висит. Очень важная характеристика для сервака! Плохо, конечно, что из базы нельзя выгнать пользователей Так ты не сможешь отследить на каком именно процессе у тебя запросы в очередь встают и висят..

Инн, если честно, из всего вышеизложенного мое резюме:

1. Поставить параметр, как рекомендует kadr.
2. Перевести базу на 9-ый оракл. Он все-таки побыстрее выглядит.
3. ОЧЕНЬ внимательно потестировать дисковую подсистему. По моему мнению, на базу в 160Гб четыре диска на сервер просто мало. У тебя пользователей 30-40 в этой базе? Это каждому из них надо что-то прочитать, посмотреть и т.п. Дисковая подсистема просто не справляется. Сейчас все дружно начнут кидать в меня камнями, но вместо 4-х дисков ( а на самом деле их, по-хорошему, надо штук 6), нужно 6 массива по 4-6 дисков в каждом, для обеспечения быстродействия чтения в первую очередь. База у тебя в памяти никак не поместится. Ну всё это на железе приличного уровня.