автор бесплатная поделка, использующая технологии прошлого века с конструктивно заложенными тормозами.
авторосновная проблема конечно в кривизне самого ФБ.
Лучше и не скажешь! Именно так вы правы, архитектурный просчет.

Вася УткинЛюбитель MSSQLИ SSD не спасает, так как он не выигрывает по записи у обычного SAS . Он его обгоняет на чтении.

Чушь какая-то, это где вы такой обычный SAS видели, быстрее 2800 МБ/с на запись?
Это вам RAID10 штук из 60 дисков SAS 2.5'' 10Krpm надо.
http://market.yandex.ru/product/7863931/spec?hid=91033&track=char Назначение для сервера
Скорость записи /Скорость чтения
2800 /2800 Мб/с
http://market.yandex.ru/catalog/91033/list?how=dpop&gfilter=2141208602:select&gfilter=2142356600:3200~

http://habrahabr.ru/post/200464/

автор1.С ростом количества SAS дисков в массиве все показатели только улучшаются.
2. Для MySQL медленные подсистемы это SATA RAID1 и SAS RAID1. По остальным отличия есть, но они не столь существенны.
3. Для линейно записи хороши как большие массивы из SAS дисков в RAID10, так и SSD. Смысла использовать массивы из SSD нет . Стоимость растет, а производительность на месте.
4. Для линейного чтения хороши любые большие массивы. Но на практике лин. чтение без записи у нас почти не встретить.
5. Рандомное чтение за SSD одиночными или в Software RAID.
6. Для рандомной записи лучше использовать Hardware RAID из SSD , хотя не сильно поступаются и одиночные SSD.
7. Рандомные чтение/запись , то есть один из самых важных показателей, имеют лучшие результаты на Hardware RAID из SSD .
8. Обобщая все вышесказанное, для большинства задач лучше использовать большие массивы (>=8) из SAS или Hardware RAID из SSD. Но для некоторых задач корректнее будет использовать одинарные SSD.
9. Исходя из объемов SSD, которые преимущественно предлагаются на нашем рынке, под VDS-ноды стоит использовать максимальной производительности процессоры в паре с большими SAS массивами или же средненькие процессоры и одинарные SSD. Считаю что использование hw raid для двух SSD будет дороговато.
10. Если вам необходима быстрая система и нет необходимости в большом дисковом пространстве 2x SSD в Hardware RAID будет лучшим выбором. Если желаете немного сэкономить в ущерб производительности, тогда можно взять одинарный SSD или два SSD в софтовом рейде.

Alexander A. SakНаверное, в SQL2012 какой-то неправильный лог транзакций. Иначе никак не объяснить, что восстановление невозможно.

Все с ним правильно:) Нужно просто было щелкнуть пару раз мышкой и настроить нормальное резервное копирование (автоматически):
1. Полное резервное копирование базы раз в неделю
2. Ежедневное дифференциальное копирование
3 Ежеминутное резервное копирование журнала.
И все всегда восстановиться.

В том случае, который описан:

SQL Server не позволяет копировать файлы при запущенной службе. Можно правда сделать теневую копию, если запущена служба специальная для SQL, которая разрешает такое. Но она по дефолту обычно отключена.
Я подозреваю, что были скопированы mdf файл и все, во время остановки. Но если бы еще умудрились бы скопировать ldf на 23.02, можно было бы легко восстановить.

1. Присоединяем копию mdf к серверу в виде отдельной базы, указывая на скопированный ldf.
2. Делаем полный бэкап базы.
3. Затем делаем восстановление базы в другую базу c опцией norecovery
4. Накатываем копию лога от 05.03 с опцией recovery
5. Конечно все сработает если не было бэкапов лога между 23.02 и 05.03

Dimitry SibiryakovДля линейно записи хороши как большие массивы из SAS дисков в RAID10, так и SSD.
Смысла использовать массивы из SSD нет. Стоимость растет, а производительность на
месте.
Ну, я так уже и говорил: производительность систем с логом не улучшается. Поэтому их
обходят как стоячих.


Что-то не совсем понятно, как выбор между SSD и SAS коррелирует в производительности СУБД с логом и без оного?