Добрый день,

стоит задача улучшить быстродействие продуктивной системы. Система стоит на Windows Server + Microsoft SQL. Железу и системе сейчас три года.

Просьба подсказать, на сколько может помочь:
- переход на UNIX + Oracle
- архивирование старых документов
- покупка нового железа.

Наймите хорошего базисника , можете на контракт если есть свой который занят повседневной работой. Как минимум оценит ситуацию и скажет,
всё остальное голословно, без обследования тут никак.

Добавлю еще замечание.
Стоит пообщаться с аккаунт-менеджером от SAP - смена СУБД меняет контрактные условия.

В свое время мы рассматривали такой же вариант и со своим менеджером общался - получил предварительное согласие, что это будет возможно.
Но в конечном итоге мы пошли по пути смены железа и переход на UNIX + Oracle очень далеко отложили.

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

в свете "дружбы" с ораклом более актуально Oracle vs. Sybase: 10 reasons to use Sybase on Linux

а вообще, Early Watch Alert Report показал, что при переезде с win2003+oracle10 => sles11+oracle11
производительность выросла в 6 раз

Как то смешно даже )) А бывает при таком же переезде наоборот упадет производительность.
Нужно конкретно смотреть что улучшилось, почему улучшилось ) Я не верю что просто перенесли и само заработало лучше в 6 раз.
Может если бы вы просто проапгрейдили исходник до 11 оракла то заработало бы в 12 раз лучше ? Не ?

ну почти так...
мы не нашли такое же старое железо...
перешли с IA64 на X86_64

Я правильно понимаю, что у вас продуктивная система располагается на одном сервере ?
Проводился ли анализ, что тормозит CI или DB ?

Я бы для начала попробовал CI и DB разнести по разным серверам, обычно неплохо помогает...

Судя по всему тормозит DB

ST03N: http://yadi.sk/d/l_4wE3z53LPRf

подумаем над разделением сервера приложений и базы данных.

Переход на другую ОС, версию СУБД и выгрыш в производительности в 10 раз на том же железе - фантастика.
Правильный совет - взять на время хорошего базисника, который скажет в чем дело и предложит ряд мер для улучшения ситуации.
Для проверки адекватности железа текущей версии ОС, R3, СУБД, функционалу и размеру БД делается сайзинг.
После того, как сайзинг будет сделан будет понятно, удовлетворяет железо данным требованиям или нет.
Далее можно разбираться с проблемами, либо это корявый Z код (скорее всего), либо не оптимальный ландшафт, либо пользователи тупят.

на большинство этих вопросов дает ответ Early Watch Alert Report
10 раз = фантастика ? ну может быть...
но в 6 раз на немного другом железе - это точно. 11 раздел Early Watch Alert Report про всё это в картинках...
просто гетерогенное копирование выполняет 2 важных дела сразу - reog tables & index recreating

Эти два важных дела касаются DB, А если в тормознутости системы виноват корявый Z или скажем слыбый CPU и явный недостаток памяти, то изменится мало что.

если в этом разделе диаграмма показывает, что Unknown applications занимают больше процентов, чем BC - значит система фанатеет от Z
в этом разделе 2 диаграммы - отдельно для CPU и для DB

а лидеры по прожорливости (как правило из Z) показываются в разделе 17 = Database server load from expensive SQL statements

вроде всё красиво, за одним исключением - Early Watch Alert Report можно получить только находясь на Enterprise Support-e ...
так что, либо самому разбираться, либо эксперта звать.

Сайзинг это отдельная процедура, которая рассчитывает нормативную мощность для железа-СУБД-версии-количества пользователей-размера БД и т.д. (к примеру - скорый поезд может увезти 1000 пассажиров за 7 дней пути из Москвы в Иркутск) ,
а Early Watch Alert это фикирование фактов за определенный период времени (к примеру - скорый поезд увез всего 100 пассажиров за 27 дней пути из Москвы в Иркутск).
Одно другое не заменяет.