Сидящие в одном здании 1С-ники плачут о том, что при аварийном выключении SQL сервера у них постоянно "падает база", и приходится тяжело и напряжно её поднимать (UPS'ы есть, иногда кабель случайно выдёргивают).

Мне интересно, в системе 1С 8.0 вообще знакомы с такими понятиями, как T-SQL транзакции , они применяются в коде системы? С учётом того, что MS SQL Server 2000/2005 имеет двухфазное подтверждение транзакции, и после перезапуска незавершённые транзакции просто отменяются (rollback tran), а завершённые пишутся в базу (commit tran), какой идиотский код должен сидеть в 1С, чтобы выгребать все данные на клиентов и крутить там всё в циклах и многочасовых обработках, без применения SQL транзакций для обработки данных.

1С разработчики вообще знакомы с такими базовыми конструкциями, как:
есть понимание, что это значит?
И что нужно сделать, чтобы избежать этого загадочного и тяжкого " падения базы "?

Sincerely yours,
Valery Chesnokov
chv.tele-kom.ru

anjeyЕсть парочка советов:

1. Что-бы не выдергивали шнур, его нужно припаять или хотя бы прикрутить эзоляционной лентой.
2. После припайки шнуров нужно тупо ждать версию 1С примерно эдак 12.2-12.3... Тогда появятся транзакции... причем с ножным управлением... ручное управление уже есть (так писали где-то в соседнем топике)С п.1 полностью согласен - админам нужно навести порядок в серверной.
2. Но ближе к реальности - на базе 1С 8.0 реально получить отказоустойчивую систему обработки данных без "падения"? Кому нужно выпрямить руки - создателям 1С, или тем, кто пишет на ней конфы, не зная SQL?

Да, нашёл в топике на http://www.sql.ru/forum/actualthread.aspx?tid=384624 - Основные новые возможности платформы 1С:8.1 упоминание:
gybsonРежим управляемых блокировок в транзакции. Позволяет управлять блокировками данных и повышает параллельность работы пользователейЗдесь имеются ввиду нормальные SQL транзакции (см. пример T-SQL в начале темы), что именно они будут применяться в 1С, не какие-то свои собственно-изобретённые?

Sincerely yours,
Valery Chesnokov
chv.tele-kom.ru

gybson"Слышал звон, да не знаю где он", вот как это называется.

По умолчанию 1С использует уровень изоляции SERIALIZABLE.

"Параметр XACT_ABORT должен иметь значение ON для инструкций изменения данных в явных или неявных транзакциях, применяющихся к большинству поставщиков OLE DB, включая SQL Server. Единственным случаем, когда этот параметр не требуется, является поддержка поставщиком вложенных транзакций.". Если читать дальше, то будет понятно, что с XACT_ABORT OFF 1С вообще не будет работать.

В общем сами сначала разберитесь в вопросе.
1. Вопрос был конкретный - использует ли 1С 8.х механизм T-SQL транзакций при пакетной обработке данных, или нет? Если да, то почему происходят нарушения ссылочной целостности в документах, и загадочное "падение" базы при выключении сервера?

Подозреваю, что ответ - нет, не использует. Если было бы "да", SQL незавершённые транзакции просто откатятся на состояние базы до их начала, и никакого "падения" и логического нарушения базы не будет. Что могут об этом сказать 1С-разработчики? В 1С это возможно?

2. По поводу SET XACT_ABORT - поднимите свой уровень знания MS T-SQL и прочитайте для начала справку в SQL BOL, для чего нужна эта команда. Она нужна не только для вложенных транзакций.
SET XACT_ABORT

Specifies whether Microsoft® SQL Server™ automatically rolls back the current transaction if a Transact-SQL statement raises a run-time error.

Syntax
SET XACT_ABORT { ON | OFF }

Remarks
When SET XACT_ABORT is ON, if a Transact-SQL statement raises a run-time error, the entire transaction is terminated and rolled back. When OFF, only the Transact-SQL statement that raised the error is rolled back and the transaction continues processing. Compile errors, such as syntax errors, are not affected by SET XACT_ABORT.

It is required that XACT_ABORT be set ON for data modification statements in an implicit or explicit transaction against most OLE DB providers, including SQL Server. The only case where this option is not required is if the provider supports nested transactions. For more information, see Distributed Queries and Distributed Transactions.

The setting of SET XACT_ABORT is set at execute or run time and not at parse time.

Examples
This example causes a foreign key violation error in a transaction that has other Transact-SQL statements. In the first set of statements, the error is generated, but the other statements execute successfully and the transaction is successfully committed. In the second set of statements, the SET XACT_ABORT setting is turned ON. This causes the statement error to terminate the batch and the transaction is rolled back.

CREATE TABLE t1 (a int PRIMARY KEY)
CREATE TABLE t2 (a int REFERENCES t1(a))
GO
INSERT INTO t1 VALUES (1)
INSERT INTO t1 VALUES (3)
INSERT INTO t1 VALUES (4)
INSERT INTO t1 VALUES (6)
GO
SET XACT_ABORT OFF -- неверно
GO
BEGIN TRAN
INSERT INTO t2 VALUES (1)
INSERT INTO t2 VALUES (2) /* Foreign key error */ -- эта ошибка не прерывает транзакцию, 1-я и 3-я записи успешно вставляются
INSERT INTO t2 VALUES (3)
COMMIT TRAN
GO

SET XACT_ABORT ON -- нужно включать перед транзакциями
GO

BEGIN TRAN
INSERT INTO t2 VALUES (4)
INSERT INTO t2 VALUES (5) /* Foreign key error */ -- эта ошибка откатит всю транзакцию
INSERT INTO t2 VALUES (6)
COMMIT TRAN
GO

/* Select shows only keys 1 and 3 added.
Key 2 insert failed and was rolled back, but
XACT_ABORT was OFF and rest of transaction
succeeded.
Key 5 insert error with XACT_ABORT ON caused
all of the second transaction to roll back. */

SELECT *
FROM t2
GO

DROP TABLE t2
DROP TABLE t1
GO

gybsonЧеловек даже не написал, что имеется в виду под "падает база". Мож там сетевой интерфейс слетает или сервис не стартует или IP новый выделяется, да вариантов миллион.Так 1С-ники и не говорят, что они понимают под этим загадочным термином. Что может "падать" в 1С базе на MS SQL?

gybson Valery Chesnokov gybsonЧеловек даже не написал, что имеется в виду под "падает база". Мож там сетевой интерфейс слетает или сервис не стартует или IP новый выделяется, да вариантов миллион.Так 1С-ники и не говорят, что они понимают под этим загадочным термином. Что может "падать" в 1С базе на MS SQL?

Ну может MS-SQL-щик скажет что может падать на сервере?Могу сказать, что ничего, если при модификации данных использовать транзакции. После выключения и поднятия сервера самостоятельно запустится процесс сверки transaction log, и по его данным сохранение либо откат транзакций.
Короче, от ответа и темы мы уходим? Что может случится с SQL базой 1С, если(?) она грамотно использует транзакционные механизмы обновления данных?

СисойПо правде говоря, у меня за 5 лет работы с SQL-версиями 1С ничего не упало.
Но внезапное отключение сервера - бардак, за это штрафовать надо.
Представьте себе человека, который полчаса правил документ, а теперь результаты его работы - коту под хвост (ну не сохранялся он, тем более, что иногда 1С-ники делают так, что ошибочно заполненный документ даже записать нельзя).Вообще говоря, если создавать системы по принципу "создал соединение с SQL базой - выполнил операцию в виде хранимой процедуры / метода веб сервиса - отключился", то пока пользователь набивает документ в форме и не "общается" с базой, если в течении этого времени происходит перезапуск сервера, то пользователю это будет безразлично. Операция записи в базу выполнится успешно, если в момент записи сервер доступен.

Вопрос, почему многие системы создаются с нарушением этого принципа, и при разовой потере соединения не могут потом после его восстановления нормально работать?
Понятно, что бардак нужно пресекать, но отказоустойчивость ПО ещё никто не отменял, мало, что происходит - сбой климат-контроля серверной, физическое повреждение LAN кабеля, система должна уметь сохранить данные в форме редактирования при их неудачном сохранении, и обеспечить сохранение этих данных спустя время при восстановлении связи с сервером. Почему такой принцип разработки ПО не делается? За это тоже штрафовать надо.

Dried Gagarin Valery ChesnokovКороче, от ответа и темы мы уходим? Что может случится с SQL базой 1С, если(?) она грамотно использует транзакционные механизмы обновления данных?
У меня другой вопрос: "если у меня SQL база 1С не "падает" при внезапном выключении питания, грамотно ли она (1С) использует транзакционные механизмы обновления данных?"Транзакция суть есть атомарное обновление. Если Ваша система это соблюдает, то могу поздравить Вас, она действительно хороша. Если же она может снять деньги с одного счёта, и не положить их на другой при любом сбое, то нет - это плохая система.

vde69увы такое не реализуемо, транкзация дает высокую вероятность более 99.9% но для каждой СУБД есть риск потери транкзации и это офицеально описано.

то есть существует минимальное время в которое крах системы повлечет неоднозначность выполнения транкзацииСогласен, 100% гарантии сохранности не даст никто. Но когда после каждого выключения сервера слышишь стенания 1Сников о "падении базы", у меня есть твёрдое убеждение, что эти сопли прикрывают их некомпетентность и неумение создать надёжную систему обработки данных.

DmitryOrlov
Точно. Ножки кривые у сервера. Называют же пользователи монитор компьютером. А эти называют сервер базой. Так вот когда они слишком сильно дергают за припаянный шнурок, сервер просто физически заваливается на бок. То есть - "падает база". Вот и все объяснение Не всё так печально :) сервер лежит в стойке, как ему и положено, среди кучи таких же собратьев. То, что провода в серверной нужно перебрать, это да, админов озадачим. А во всём остальном с железом порядок, так что если у других людей, кто здесь отвечал, 1С база не падает при выключении, значит глюки идут у тех, кто сопровождает эту базу, я верно понял мысль?