Планируем переход на новые версии BI и R/3.
В связи с этим рассматриваем возможность разделения Приложения и СУБД.
Подскажите, пожалуйста, у кого такое реализовано? Как можно оценить целесообразность?

разделения в смысле по разным серверам?
наверное уже сами пришли к необходимости разделения по причине производительности
тогда в чем вопрос?

Причина разделения.
Мы обновляем серверную инфраструктуру. Покупаем новое оборудование. Если утрировать - несколько одинаковых серверов. Часть существующих серверов хотим виртуализировать. Но все виртуализировать нельзя - довольно высокие требования к IOPS-ам у R/3 и BW - систем. Поэтому рассматриваем возможность виртуализации сервера приложений, оставив сервер БД невиртуализированным.
Кроме того, всему объему требований sizing-а каждый серверов из серверов в отдельности не отвечает, в частности из-за завышенных требований на исходные данные под sizing.
Исходя из всего этого разделение мощностей серверов под SAP-системы на сервера приложений и сервера БД было бы логичным выходом.

К сожалению, как раз-таки оценить изменение производительности не можем. Отсюда и вопросы.
Например, следующий аспект. Серверы связаны между собой, производительность "железной" сетевой подсистемы высокая. Но на логическом уровне будут ли задержки, например, из-за TCP между сервером Приложения и сервером БД (Oracle)?
На какие вещи еще смотреть, решая вопрос о целесообразности такого разделения?

Распределение базы данных и серверов приложений - это всегда шаг в сторону повышения общей производительности. Стандартное и очень распространенное решение. Гигабитной сети между серверами обычно достаточно чтобы она не была узким горлом.
Но относительно виртуализации - я, к примеру, никогда не понимал таких решений на продуктивных системах. Виртуализация обычно используется для того, чтобы на одной мощной машине запустить несколько разных задач, чтобы полностью утилизировать аппаратные ресурсы.
Для продуктива же сап обычно ситуация ровно наоборот - есть одна большая задача, для решения которой ресурсов одной железки недостаточно. Их нужно использовать несколько в связке между собой. Так зачем же при этом еще и дробить ресурсы каждой из этих железяк с помощью виртуализации, если ее целиком мало? Помню, одного из таких задвинутых на виртуализации клиентов, с помощью такой аргументации удалось убедить отказаться от этой идеи.
Кстати, IOPSы при виртуализации обычно ограничением не являются. С дисковым вводом/выводом современные виртуальные системы справляются весьма неплохо. А вот SAPSов в одну виртуальную машину можно засунуть весьма ограниченное количество.

adem, спасибо за замечание.
Одной железяки недостаточно для всей задачи. Две железки (обе с большими и одинаковыми ресурсами) - для задачи многовато. Тогда задачу можно поделить на две (Приложение + СУБД). Под одну из задач (СУБД) отдать целиком всю железку№1, а под другую (SAP Application)- часть железки№2.
adem, откуда такая информация? И правильно я сделал вывод: получается, что иногда целесообразнее виртуализировать СУБД а не SAP Application?

из опыта: сервер приложений SAP потребляет больше памяти и процессорных ресурсов, чем СУБД
поэтому на похожем на ваш вариант оборудовании (2 одинаковых сервера) мы настроили следующее распределение инстанций

сервер1: СУБД и центральная инстанция CI
сервер2: диалоговая инстанция D1

далее с помощью логон-групп и числа рабочих процессов на CI и D1 добились равномерного использования памяти и процессоров

вариант с виртуализацией возможно оправдан в вашем случае, правда непонятно почему вы решили дать "пол-сервера" серверу приложений, а не базе

Ludens, спасибо.
Чтобы отдать "половину" сервера, нужно воспользоваться средствами виртуализации.
При этом у нас есть:

1. Рекомендация производителя серверов (HP):
«Виртуализовать database instance в продуктиве не рекоммендуется, SAP как приложение - пожалуйста, но с учетом overhead.»
overhead (здесь) - потери производительности на управление средствами виртуализации.

2. SAP-нота 1409608 - Virtualization on Windows

Правильно я понимаю, что с вашей точки зрения это не всегда правильно?

базу не рекомендуется помещать в виртуальную машину, ок
но что мешает рядом с ней поднять дополнительную инстанцию sap?

недостающие saps'ы доберете виртуальной машиной со второго сервера

разделить можно по Note 821904
у вас на дб сервере останется Message Service и Enqueue Service которые нагрузки на дб сервер практический не дают.