Являются ли распределенные транзакции хорошей идеей для включения отката обновлений базы данных в пользовательских действиях установщика Windows?

Question

Я перерос пользовательские действия на Sql Server, доступные в WiX, поэтому я предпринял смелый шаг по созданию своего собственного, используя Deployment Tools Foundation.Я хочу быть хорошим гражданином и позаботиться о том, чтобы мои поддержали откат.Но как лучше всего это сделать?

Мне нужно поддерживать SQL Server 2005 и более поздние версии всех выпусков.

Проблема, на мой взгляд, заключается в том, что установщик Windows работает в два этапа: он делает работу, сохраняя информацию об отмене по ходу дела.Затем, когда все части на месте, он либо фиксирует (удаляя информацию об отмене), либо выполняет откат.

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

Я подумал о том, чтобы взять резервную копию только для копирования базу данных, которую я могу восстановить в действии отката при необходимости, но я думаю, что этот подход, хотя и простой, имеет недостатки.Например, я не знаю, насколько большими будут наши базы данных - поэтому я не могу гарантировать, что будет достаточно места для хранения резервной копии на целевой машине.Кроме того, резервное копирование и восстановление могут занять некоторое время, и я не хочу, чтобы обычные установки (где откат не происходил) были излишне медленными.

Так что это подводит меня к моей текущей предпочтительной идее: makeубедитесь, что координатор распределенных транзакций запущен, затем инициализируйте распределенную транзакцию перед внесением изменений, затем либо фиксируете ее, либо откатываете в соответствующих пользовательских действиях.

Кажется, я могу использовать элементы TransactionInterop класс для экспорта файла cookie, который позволит мне разделить транзакцию между моими различными настраиваемыми действиями.

Может ли кто-либо, имеющий опыт такого рода вещей, сказать, может ли он работать?

Answer 1

Некоторые операции базы данных / экземпляра нельзя выполнить внутри транзакции (например, CREATE / ALTER / DROP ENDPOINT), а другие операции нельзя выполнить внутри распределенной транзакции (например, SAVE TRANSACTION).Таким образом, вы не сможете сделать их вообще в предложенном вами плане.Также ваши скрипты обновления БД должны будут работать правильно при запуске внутри незафиксированной транзакции.

Я бы сказал, что существует меньший риск перехода по пути резервного копирования / восстановления (или, альтернативно, создания моментального снимка базы данных и восстановления из моментального снимка при откате с недостатком EE).

Также можно использовать сценарий undo для каждого сценария do, выполняемого во время обновления, и запускать сценарий отмены во время отката и устранять последствия установки.Я понимаю, что это проблема hard , которая, вероятно, удваивает количество сценариев, которые должны быть разработаны (и протестированы ...), и требует серьезной дисциплины разработчика.

Answer 2

За прошедшие годы я сделал довольно много инсталляторов со сценариями SQL, и я пришел к мнению, что он подходит только для простых баз данных, например, вот мое приложение VB с локальной базой данных MSDE / MySQL или вот мое локальное хранить для поиска в таблице кодов и временных фиксаций, пока мы ждем, чтобы синхронизировать его где-то еще.

Как только вы попадаете в тяжелые ситуации промышленного типа, я хотел бы вывести конфигурацию БД из установщика и включить ее в приложение в качестве истории первого запуска. Вы можете сделать намного более тяжелую работу с C # там и не быть ограниченным MSI.