|
в 1С не нужно SET ALLOW_SNAPSHOT_ISOLATION ON | ☑ | ||
---|---|---|---|---|
0
vi0
13.04.14
✎
15:08
|
Ищу подтверждения своего понимания SNAPSHOT в 1С 8.3
Исходя из документации MSDN вижу, что чтобы включить уровень изоляции транзакции "Read committed snapshot" достаточно выполнить инструкцию: ALTER DATABASE ИмяБазы SET READ_COMMITTED_SNAPSHOT ON и не требуется выполнять ALTER DATABASE ИмяБазы SET ALLOW_SNAPSHOT_ISOLATION ON Это также подтверждают тесты, которые я делал в SQL Server, а также тот момент, что 1С 8.3 при создании новой базы выполняет инструкцию ALTER DATABASE ИмяБазы SET READ_COMMITTED_SNAPSHOT On WITH ROLLBACK IMMEDIATE и не выполняет инструкцию ALTER DATABASE ИмяБазы SET ALLOW_SNAPSHOT_ISOLATION ON Но в некоторых статьях по 1С эти инструкции всегда идут парой. Насколько я понимаю, инструкция ALTER DATABASE ИмяБазы SET ALLOW_SNAPSHOT_ISOLATION ON имеет другое назначение и оно описано в документации MSDN. ВОПРОС: Может кто нибудь сказать что _для 1С_ требуется SET ALLOW_SNAPSHOT_ISOLATION ON и для чего именно? |
|||
1
ДенисЧ
13.04.14
✎
15:11
|
"Папа, а ты с кем сейчас говорил?" (с)
|
|||
2
Torquader
13.04.14
✎
15:20
|
Так вы хотите изоляцию по подтверждённым на момент запуска ?
Что происходит потом, когда кто-то другой подтверждает параллельную транзакцию ? |
|||
3
vi0
13.04.14
✎
15:22
|
(2) Я хочу уровень изоляции транзакции "Read committed snapshot". Т.е. тот, который предлагает 1С 8.3
|
|||
4
vi0
13.04.14
✎
15:24
|
(2) на момент запуска чего?
|
|||
5
Torquader
13.04.14
✎
15:29
|
В общем, SET ALLOW_SNAPSHOT_ISOLATION ON включает сохранение версий строк во временной базе TEMPDB.
Данные в транзакции "замораживаются" на момент её начала. Поэтому, если в параллельной транзакции будет попытка сделать COMMIT уже считанных данной транзакцией данных, то произойдёт ошибка транзакции. |
|||
6
vi0
13.04.14
✎
15:30
|
я говорю о статьях которые предлагают включить "Read committed snapshot" вручную в 8.2
|
|||
7
Torquader
13.04.14
✎
15:31
|
SET READ_COMMITTED_SNAPSHOT ON включает доступ к версиям по умолчанию READ_COMMITED.
|
|||
8
vi0
13.04.14
✎
15:31
|
(5) ну так, а если в контексте моего вопроса?
|
|||
9
Torquader
13.04.14
✎
15:32
|
Для 1С лучше всего обеспечивать режим транзакций REPEATABLE READ, так как это гарантирует правильность выполнения расчётов.
|
|||
10
vi0
13.04.14
✎
15:35
|
(9) это оффтоп)
|
|||
11
Torquader
13.04.14
✎
15:45
|
https://docs.tibco.com/pub/collaborative_information_manager/8.3.0_april_2013/doc/html/tib_cim_8.3.0_installation/wwhelp/wwhimpl/common/html/wwhelp.htm#href=tib_mdm_Setting_up_Databases.09.5.htm&single=true
Там написано, что включение двух этих режимов приводит к блокировке на уровне таблиц. То есть, вполне логично, что инструкция не выполняется при работе с управляемыми блокировками. |
|||
12
Torquader
13.04.14
✎
15:53
|
||||
13
vi0
13.04.14
✎
15:58
|
(12) это все хорошо и полезно, но не отвечает на мой вопрос
|
|||
14
Torquader
13.04.14
✎
16:10
|
||||
15
vi0
13.04.14
✎
16:14
|
(11) если ты про эту строку
"For the READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION levels, the read operations acquire only the Schema Stability (Sch-S) table level locks. It does not lock any pages or rows." То здесь говорится что выполняется только блокировка схемы, если правильно понял. И как раз это позволяет уменьшить блокировки в базе. |
|||
16
vi0
13.04.14
✎
16:15
|
(14) это одна из статей про которые я говорил
мне интересно для чего авторы используют SET ALLOW_SNAPSHOT_ISOLATION ON |
|||
17
NcSteel
13.04.14
✎
16:20
|
(6) Вруную включать нельзя - нарушение лицензии.
|
|||
18
hhhh
13.04.14
✎
16:23
|
(16) да, вручную там ничего не меняйте, а то фирма 1с вас вычислит и отправит на Магадан.
|
|||
19
Torquader
13.04.14
✎
16:24
|
http://sqlpub.narod.ru/Publications/021501SnapshotIsolation.htm
Предположительно, данная опция также выключает режим блокировок при чтении. |
|||
20
vi0
13.04.14
✎
16:27
|
(19) Попробую акцентировать еще раз на своем вопросе:
В контексте платформы 1С, не важно вручную для 8.2 или как то иначе для 8.3 требуется ли выполнение SET ALLOW_SNAPSHOT_ISOLATION ON если требуется то зачем? |
|||
21
Torquader
13.04.14
✎
16:30
|
||||
22
vi0
13.04.14
✎
16:33
|
еще на всякий случай добавлю
я понимаю для чего нужна инструкция SET ALLOW_SNAPSHOT_ISOLATION ON |
|||
23
Torquader
13.04.14
✎
16:39
|
Включение версионирования в 1С приводит к тому, что разные сеансы могут видеть разные данные (так как изменения происходили в разное время), и, как результат, делать неправильные вычисления.
Если версионирования нет, то кто-то видит данные, а кто-то ожидает (в блокировке) пока они будут видны. |
|||
24
vi0
13.04.14
✎
17:31
|
(23) ты решил весь инет сюда процитировать?)
|
|||
25
Torquader
13.04.14
✎
17:38
|
(24) Ну, вот видишь, ты уже полностью подошёл к мысли, что всё важное и нужное надо искать самому.
|
|||
26
hhhh
13.04.14
✎
17:40
|
(24) вы просто не на тот форум зашли. На SQL форумах спросите.
|
|||
27
vi0
13.04.14
✎
17:44
|
(26) дело в том, что эта тема касается именно 1с
я видел хорошие обсуждения на форуме sql, но это в контексте SQL Server, здесь вопрос именно по платформе 1с как вообще обстоит с этими инструкциями я понимаю |
|||
28
vi0
13.04.14
✎
17:50
|
еще раз
в статьях про ручной перевод конф 8.2 на версионник пишут, что нужно выполнить: ALTER DATABASE ИмяБазы SET READ_COMMITTED_SNAPSHOT ON ALTER DATABASE ИмяБазы SET ALLOW_SNAPSHOT_ISOLATION ON я вижу, что достаточно выполнить ALTER DATABASE ИмяБазы SET READ_COMMITTED_SNAPSHOT ON и именно это делает платформа 8.3 при создании базы |
|||
29
Torquader
13.04.14
✎
17:52
|
(28) Проведи эксперимент на тестовой базе и посмотри, что происходит.
Результат желательно изложить здесь. |
|||
30
vi0
13.04.14
✎
17:55
|
(29) я провел его в SQL Server, и написал это в сабже
|
|||
31
vi0
13.04.14
✎
17:56
|
результат такой, что записывающая транзакция не блокирует читающую
|
|||
32
hhhh
13.04.14
✎
18:07
|
что это вообще такое "перевод конф на версионник"? Что за птица такая?
|
|||
33
vi0
13.04.14
✎
18:11
|
(32) если кратко, то это способ реализации многопользовательской работы в БД, где в случае параллельность достигается не блокированием изменяемых данных, а созданием своей версии для каждой читающей транзакции (может быть не совсем для каждой..)
|
|||
34
vi0
13.04.14
✎
18:11
|
"в случае" - это лишнее
|
|||
35
Torquader
13.04.14
✎
18:18
|
(31) Так эта команда как раз такой режим и включает.
|
|||
36
hhhh
13.04.14
✎
18:20
|
(33) тогда причем создание базы? База создается в монопольном режиме. Там один пользователь.
|
|||
37
vi0
13.04.14
✎
18:23
|
(36) эту команду нужно выполнить единовременно для базы в целом
|
|||
38
vi0
13.04.14
✎
18:26
|
(35) документация говорит, что
ALTER DATABASE ИмяБазы SET ALLOW_SNAPSHOT_ISOLATION ON требуется для уровня изоляции транзакции SNAPSHOT т.е. когда используется инструкция SET TRANSACTION ISOLATION LEVEL SNAPSHOT но я не вижу, чтобы она в 1С использовалась |
|||
39
hhhh
13.04.14
✎
18:32
|
(38) что за документация?
|
|||
40
vi0
13.04.14
✎
18:46
|
||||
41
hhhh
13.04.14
✎
21:37
|
это майкрософт документация, не 1с.
|
|||
42
floody
13.04.14
✎
21:52
|
(40) если для вас это такой животрепещущий вопрос, то может быть вам спросить об этом например славу гилева..
|
|||
43
Федя Тяпкин
13.04.14
✎
22:00
|
кажется в книжке по эксперту было подробное описание режимов. в каких версиях какой по умолчанию и на что влияют.
|
|||
44
Necessitudo
13.04.14
✎
22:39
|
(43) А что за книжка про эксперта?)
|
|||
45
vi0
14.04.14
✎
07:04
|
||||
46
vde69
модератор
14.04.14
✎
08:02
|
(38) зачем тебе это????
на сколько я понял фишка snapshot это то что внутри сеанса который начал транзакцию ты при чтении получаешь данные которые были ДО начала транзакции... то есть запрет грязного чтения даже внутри транзакции.... для 1с такой уровень изоляции в обячной работе нельзя устанавлитать, по тому как в этом случае внутри модуля проведения ты не будешь иметь доступа к новым движениям ... |
|||
47
vi0
14.04.14
✎
10:59
|
(46) если ты про SET TRANSACTION ISOLATION LEVEL SNAPSHOT то я и говорю, что это не нужно
|
|||
48
Леша1с
14.04.14
✎
11:02
|
(27)"как вообще обстоит с этими инструкциями я понимаю"
суть в том, что никто не понимает, как, каким образом, и когда это будет реализовано у 1С. |
|||
49
Леша1с
14.04.14
✎
11:04
|
(41)"это майкрософт документация, не 1с."
у 1С как-бы нет своей СУБД... Десятилетиями использует SQL. |
|||
50
Леша1с
14.04.14
✎
11:05
|
(46)"зачем тебе это????"
правильно, 1С как всегда реализует все своим любимым местом. |
|||
51
Torquader
14.04.14
✎
11:05
|
(46) На самом деле, там если всё правильно настроить, то никто не получит то, что было после - а при попытке фиксации транзакции, будет её откат.
Весь вопрос ещё в том, что бывают ReadOnly транзакции, которые данные не изменяют. В случае snapshot мы выключаем какие-либо блокировки базы транзакциями, только читающими данные, так как они радостно читают свой snapshot и для отчётов, например, это даже лучше, так как весь отчёт снимается на какой-то один момент времени, а не как бог на душу положит. |
|||
52
Леша1с
14.04.14
✎
11:08
|
(46)"ты при чтении получаешь данные которые были ДО начала транзакции"
вы не то что-то написали. Пока транзакция не закончена - данные так и остаются в "исходном" (до транзакции) состоянии. Суть в том, что методом создания снапшота на уровне СУБД (не 1С!!!!! забудьте, это уровень СУБД, SQL и MS) обходится блокировка таблиц, по которым выполняется транзакция/ |
|||
53
Леша1с
14.04.14
✎
11:09
|
+ обходитсмя для чтения, запись все также стоит в очереди, как и было.
|
|||
54
Torquader
14.04.14
✎
11:09
|
(52) Просто, если такой режим в транзакции обновления данных, то можно получить совсем не то, что ожидали - особенно, когда оба сеанса одновременно обновляют данные.
|
|||
55
Леша1с
14.04.14
✎
11:10
|
(46)" по тому как в этом случае внутри модуля проведения ты не будешь иметь доступа к новым движениям ..."
можно предположить, что сейчас в 1С мы имеем доступ к данным (к движениям) ВНУТРИ транзакции? |
|||
56
Леша1с
14.04.14
✎
11:12
|
(54)" по тому как в этом случае внутри модуля проведения ты не будешь иметь доступа к новым движениям ..."
сныпшот не работает "на запись". Это сугубо "для чтения". А для чтения - разницы никакой: сеанс прочитал данные, которые через секунду (10 сек, час, день) будут изменены. |
|||
57
Леша1с
14.04.14
✎
11:12
|
*ответ на
"то можно получить совсем не то, что ожидали - особенно, когда оба сеанса одновременно обновляют данные." *снапшот |
|||
58
Torquader
14.04.14
✎
11:13
|
(56) Так если мы включаем уровень изоляции транзакций, то они могут писать данные в таблице, и не встречать блокировок при этом, блокировка встречается уже при фиксации транзакции.
|
|||
59
hhhh
14.04.14
✎
11:14
|
(49) она использует SQL в урезанной форме. Поэтому глупо брать документацию c сайта майкрософт.
|
|||
60
Леша1с
14.04.14
✎
11:14
|
+ 53 в очереди блокировок.
(54) снапшотом обходят сугубо блокировки при чтении, и не более того. |
|||
61
Torquader
14.04.14
✎
11:14
|
(57) Вы ещё вспомните, как ведётся работа в 1С - сначала мы запросом получаем данные, а потом начинаем что-то куда-то записывать по данным этого запроса.
|
|||
62
Леша1с
14.04.14
✎
11:16
|
(59) о том и речь:
- 1С не использует SQL и на 10% - никто не знает, как 1С реализует "снапшот" (возьмет "обрезку", или подключится к "полнрой реализации" снапшота) - гадать про 1С - дело неблагодарное, но глупое. |
|||
63
Леша1с
14.04.14
✎
11:17
|
(61)" а потом начинаем что-то куда-то записывать по данным этого запроса."
вот когда будете писать, то будете писать уже на "общих" основаниях со всеми блокировками и очередями записи. |
|||
64
Torquader
14.04.14
✎
11:18
|
(63) Так это понятно, только данные-то могут поменяться, если на стадии чтения мы не встретили блокировки.
|
|||
65
Леша1с
14.04.14
✎
11:22
|
+ 63
если имеете в виду, что получили данные чтением с помощью снапшота, приняли решение на их основе писать что-то, а в это время другая параллельная транзакция уже изменила именно эти данные (которые прочли, или которые собрались писать) - то просто будет откат таких ваших действий. Предполагаю, что в MS именно так и реализовано - чтение снапшота и последующая запись "туда же", где уже все модифицировала транзакция, параллеьная снапшоту. Это все-таки не 1С. |
|||
66
Torquader
14.04.14
✎
11:24
|
(65) Если в одной транзакции - то да - будет откат.
Только вот при работе в 1С вместо записи получать откаты - так это вместо работы только жмаканье кнопок на удачу и останется. |
|||
67
Леша1с
14.04.14
✎
11:24
|
+ 65 а вот, боюсь, в 1С будет реализован именно вариант "без контроля", в результате получим полностью неуправляемыей механизм, который будет писать данные на "основе снапшота", а не реального положенрия с учетом прошедших изменений.
|
|||
68
Леша1с
14.04.14
✎
11:25
|
(66) именно
так что с 8.3-4-5 торопиться в промышленных базах ой как не надо еще лет 5. |
|||
69
Torquader
14.04.14
✎
11:25
|
Особенно хорошо, когда код разбит на несколько транзакций - одна завершилась - другая - откатилась, и теперь нам нужно откатить (точнее отыграть назад) предыдущую - а её уже кто-то "перекрыл" - и всё. В результате работы алгоритма данные в базе пришли в "нестабильное состояние".
|
|||
70
Леша1с
14.04.14
✎
11:26
|
(69)"когда код разбит на несколько транзакций"
именно "песочницу" (дискретное выполнение кода) 1С не может реализовать, уже видимо, никогда. |
|||
71
Леша1с
14.04.14
✎
11:28
|
(69)"В результате работы алгоритма данные в базе пришли в "нестабильное состояние"."
прсото сошлются на "неактуальность механизмов снапшота" и по-тихоньку сольют тему в новых релизах, попутно направив внимание 1с-ников на новые перделки-зазеркалки. |
|||
72
vi0
14.04.14
✎
11:31
|
у меня нет претензий к 1с и к ее реализации snapshot
я вижу, что там все корректно |
|||
73
Torquader
14.04.14
✎
11:32
|
(70) Так это никто реализовать не может, в принципе - так как нужно предусматривать возможность отмены непоследней транзакции без последствий.
|
|||
74
vi0
14.04.14
✎
11:33
|
не забывайте, что snapshot включается только при наличии управляемых блокировок
|
|||
75
Torquader
14.04.14
✎
11:34
|
(74) Он включается командой при начале транзакции, а вот когда 1С эту команду даёт - это уже её (1С) дело.
|
|||
76
vi0
14.04.14
✎
11:41
|
(75) Транзакция начинается или явно программистом или неявно при записи - тут все прозрачно. И до записи/считывания нужно сначала пройти сквозь слой управляемых блокировок.
|
|||
77
Torquader
14.04.14
✎
11:44
|
(76) Это всё понятно, просто 1С, открывая соединение к базе данных, "устанавливает правила игры", то есть делает некоторые установки - что и как она будет читать.
Весь вопрос в том - насколько они документированы и насколько SQL-сервер полностью их понимает и обеспечивает правильное функционирование. |
|||
78
vi0
14.04.14
✎
11:48
|
(77) приведи, пожалуйста, пример, когда
> 1С, открывая соединение к базе данных, "устанавливает правила игры", то есть делает некоторые установки |
|||
79
Torquader
14.04.14
✎
11:50
|
(78) Так лови параметры подключения - там всё должно быть указано, если что-то не менялось, то будет то, что по-умолчанию установлено на сервере.
|
|||
80
Леша1с
14.04.14
✎
11:51
|
(78) любое обращение к SQL - это установка 1С своих правил (отсуствие каких-либо правил - тоже "установка правил игры").
|
|||
81
vi0
14.04.14
✎
11:57
|
(79) так у тебя конкретно к чему претензии?
|
|||
82
vi0
14.04.14
✎
11:58
|
(80) так можно сказать про любого разработчика SQL, что он устанавливает "свои правила игры" взаимодействуя с SQL
|
|||
83
Torquader
14.04.14
✎
11:59
|
(82) Ну а что - не так что-ли ?
Все режимы SQL прекрасно задокументированы - выбирай любой, только потом не обижайся, что работает так, как написано. |
|||
84
Infsams654
14.04.14
✎
12:02
|
(81) А у тебя к чему? 1С сделала под MS SQL, Oracle и т.д? В чем проблемы ? Какая-то реализация под эти СУБД все-таки должна быть, даже, если тебя не устраивает. Забей..
|
|||
85
vi0
14.04.14
✎
12:04
|
(84) ну так прочти сабж для начала
|
|||
86
Torquader
14.04.14
✎
12:04
|
(84) Ну и не со всеми там всё гладко и успешно.
|
|||
87
vi0
14.04.14
✎
12:04
|
(83) а у кого работает не так?
|
|||
88
Леша1с
14.04.14
✎
12:07
|
(82)" так можно сказать про любого разработчика SQL"
можно. Только, в отличие от 1С-разработчиков, они все строго документируют, и мы можем прекрасно посмотреть на той же MSDN, что почем. |
|||
89
vi0
14.04.14
✎
12:22
|
(88) а чего тебе не хватает в документации 1с как для разработчика?
|
|||
90
Леша1с
14.04.14
✎
12:31
|
(89) мне, как и всем пытающимся разобраться в этой свалке, не хватает внятного описания - что, зачем и почему.
Вот они написали, что "сделали снапшот". Зачем? Почему именно так? |
|||
91
Леша1с
14.04.14
✎
12:32
|
+ что теперь, каких действий СУБД и базы 1С ожидать от их такой реализации?
|
|||
92
vi0
14.04.14
✎
12:49
|
(91) возможно минимального описания от них не помешало бы
но они поддерживают несколько субд, и в каждой свои особенности реализации уровней изоляции транкций в 8.2 был просто Read Commited для SQL Server - все можно посмотреть было в документации MS сейчас расширили до Read Commited Snapshot - тоже все написано в онлайне и книгах |
|||
93
vi0
14.04.14
✎
12:50
|
а зачем? ответ простой - уменьшить блокировки
|
|||
94
Леша1с
14.04.14
✎
13:48
|
(92)"но они поддерживают несколько субд"
я бы сказал, что поддерживают одну (MS), а в остальных "играются" )) |
|||
95
hhhh
14.04.14
✎
13:56
|
(94) ну, может они поддедживают несколько MS SQL?
|
|||
96
vi0
14.04.14
✎
13:58
|
(95) поддерживают
|
|||
97
mistеr
14.04.14
✎
14:10
|
(0) Насколько я понимаю, READ_COMMITTED_SNAPSHOT без ALLOW_SNAPSHOT_ISOLATION работать не будет. Последняя опция более глобальная. Если 1С ее не устанавливает, вероятно она уже включена.
|
|||
98
Леша1с
14.04.14
✎
14:15
|
(97)" Если 1С ее не устанавливает, вероятно она уже включена."
Кем? |
|||
99
mistеr
14.04.14
✎
14:21
|
(98) По умолчанию, например.
|
|||
100
Леша1с
14.04.14
✎
14:47
|
(99) по умолчанию включен снапшот изолейшн?!
Т.е. поставил SQL, и повалились ошибки из-за конкуретного изменения данных? |
|||
101
Леша1с
14.04.14
✎
14:49
|
(97)"Насколько я понимаю, READ_COMMITTED_SNAPSHOT без ALLOW_SNAPSHOT_ISOLATION работать не будет"
почему же, для чтения-без-блокировок достаточно READ_COMMITTED_SNAPSHOT. Другое дело, что 1С В ПРИНЦИПЕ НЕ ПОЗВОЛЯЕТ гибко поднастраивать КАЖДЫЙ запрос. А лишь "или все снапшотим, или идите лесом". |
|||
102
Леша1с
14.04.14
✎
14:55
|
+ READ_COMMITTED_SNAPSHOT именно и придуман для отчетов с неперекрывающимся чтением, а не изменений.
А вот ALLOW_SNAPSHOT_ISOLATION (точнее, явное указание SET TRANSACTION ISOLATION LEVEL SNAPSHOT) позволяет читать постоянно меняющиеся данные в "тяжелом" отчете, т.е. когда данные модифицируемой таблицы успевают "изменится" за время работы отчета, и в начале он прочитал одно значение, а в конце - получил уже другое, модифицированное. Вот ALLOW_SNAPSHOT_ISOLATION и призван убрать это разногласие. |
|||
103
vi0
14.04.14
✎
14:59
|
(101)
> Другое дело, что 1С В ПРИНЦИПЕ НЕ ПОЗВОЛЯЕТ гибко поднастраивать КАЖДЫЙ запрос. вот я и грю, что ALLOW_SNAPSHOT_ISOLATION лишняя тема |
|||
104
Леша1с
14.04.14
✎
15:01
|
(103) 1С в любом случае не позволяет рулить настройками каждого запроса.
Так что хоть то, хоть это. |
|||
105
vi0
14.04.14
✎
15:05
|
(104) то это - это что?
|
|||
106
Леша1с
14.04.14
✎
15:26
|
(104) READ_COMMITTED_SNAPSHOT вы тоже гибко под запрос выставляете?
|
|||
107
mistеr
14.04.14
✎
15:26
|
(100) >по умолчанию включен снапшот изолейшн?!
If you change the setting for model, that setting becomes the default for any new databases that are created, except for tempdb. The option is ON, by default, for the master and msdb databases. http://technet.microsoft.com/en-us/library/bb522682.aspx (102) >READ_COMMITTED_SNAPSHOT именно и придуман для отчетов с неперекрывающимся чтением, а не изменений. Заблуждение. (103) >ALLOW_SNAPSHOT_ISOLATION лишняя тема Snapshot isolation must be enabled by setting the ALLOW_SNAPSHOT_ISOLATION ON database option before it is used in transactions. http://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110).aspx Я понимаю так, что READ_COMMITTED_SNAPSHOT тоже входит в "use in transactions". Проверить сейчас не на чем. Проверь, если можешь. |
|||
108
vi0
14.04.14
✎
15:34
|
(106) если это мне вопрос то я не понял зачем вы мне его задаете
был диалог (103), (104) и мне стало непонятно что вы имеете ввиду под "Так что хоть то, хоть это" |
|||
109
vi0
14.04.14
✎
15:35
|
(107) там по русски есть документация
|
|||
110
vi0
14.04.14
✎
15:36
|
(107) лишняя тема - имел ввиду лишняя вкупе с READ_COMMITTED_SNAPSHOT
|
|||
111
Леша1с
14.04.14
✎
15:36
|
(108) потому что в любом случае выйграем на одном запросе, но потеряем на другом.
|
|||
112
vi0
14.04.14
✎
15:39
|
(111) опять загадками говорить изволите
|
|||
113
vde69
модератор
14.04.14
✎
16:52
|
я вообще не понимаю зачем лезть в потраха 1с? кому-то не хватает ее скорости???
1с штатно работает без проблемм, нафига придумывать себе и другим геморой? |
|||
114
Зойч
14.04.14
✎
16:52
|
>>1с штатно работает без проблемм
Ха-ха |
|||
115
Зойч
14.04.14
✎
16:53
|
||||
116
Зойч
14.04.14
✎
16:58
|
READ_COMMITTED_SNAPSHOT - обеспечивает statement consistency;
ALLOW_SNAPSHOT_ISOLATION - обеспечивает transaction consistency при условии явного указания SET TRANSACTION ISOLATION LEVEL SNAPSHOT |
|||
117
vi0
14.04.14
✎
17:00
|
(113) чтобы принимать решения при разработке осознанно
|
|||
118
vde69
модератор
14.04.14
✎
17:01
|
(114) может кто-то не умеет готовить 1с штатно? согласно их рекомендациям?
(115) зачем тут этот пруф? ну обсуждают этот уровень изоляции как коня в вакууме, сабж имеет смысл обсуждать только в привязке к 1с. |
|||
119
Зойч
14.04.14
✎
17:03
|
(118) Сколько в самой большой базе у тебя человек работает?
|
|||
120
vde69
модератор
14.04.14
✎
17:05
|
(119) высоконагруженные системы нужно делить на фронт и бек, если этого мало, то делаются консолидированые центры.
это обычный подход к большим базам. городить одну базу на все и для всех - вообще смысла не вижу. зы много, есть такой холдинг как ГлавСтрой.... |
|||
121
vde69
модератор
14.04.14
✎
17:07
|
||||
122
vi0
14.04.14
✎
17:12
|
(118) тема ветки только про привязку к 1с, хотя многие уходят в офтоп методично
|
|||
123
Зойч
14.04.14
✎
17:14
|
(122) ты уже понял разницу между этими режимами?
|
|||
124
vi0
14.04.14
✎
17:15
|
(123) а я не говорил, что не знал
|
|||
125
krbIso
14.04.14
✎
17:21
|
(0)все верно ты понимаешь.
Статьи от вендора? Если нет, то лесом. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |