Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 alter synonyms  [new]
Greenhorn
Member

Откуда:
Сообщений: 311
Добрый день.

+ print @@version
Microsoft SQL Server 2005 - 9.00.5254.00 (X64) 
Dec 18 2010 22:50:56
Copyright (c) 1988-2005 Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2)

Есть технологический прцесс, проблемные шаги которго заключаются в следующем:
1. Создается databse snapshot справочной БД
2. Во всех БД пересоздаются synonym_ы с указанием на новый snapshot. Т.к. необходимо заменить все synonym_ы одновременно, то команды DELETE, CREATE выполняются в одной транзакции.

Так случилось, что в момент выполнения пункта 2 в одной из БД проходила интенсивная работа и synonym_ы были успешно пересозданы через полтора часа.
Но при этом часть запросов свалилась со следующим сообщением (пример):
Msg 208, Level 16, State 1, Line 3
Invalid object name 'dbo.syn_test_1'.
Неудачные попытки воспроизвести ситуацию:
+ ALTER SYNONYMs
USE [Test]
if object_id('dbo.Test_1') is NULL
  CREATE TABLE dbo.Test_1( id int )
  
truncate table dbo.Test_1
INSERT INTO dbo.Test_1 
SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 

if OBJECT_ID('dbo.Test_2') is NULL 
  CREATE TABLE dbo.Test_2( id int )
  
truncate table dbo.Test_2
INSERT INTO dbo.Test_2 
SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 

if OBJECT_ID( 'dbo.syn_test_1' ) is NULL
  CREATE SYNONYM dbo.syn_test_1 FOR dbo.Test_1

if OBJECT_ID( 'dbo.syn_test_2' ) is NULL
  CREATE SYNONYM dbo.syn_test_2 FOR dbo.Test_2
  
while 1=1
begin
  BEGIN TRAN

  DROP SYNONYM dbo.syn_test_1
  DROP SYNONYM dbo.syn_test_2

  CREATE SYNONYM dbo.syn_test_1 FOR dbo.Test_1
  CREATE SYNONYM dbo.syn_test_2 FOR dbo.Test_2

  COMMIT TRAN
end;

+ "Интенсивная работа"
use [Test]
WHILE EXISTS(SELECT 1 FROM dbo.syn_test_1 as t1 JOIN dbo.syn_test_2 as t2 ON t1.id = t2.id )
BEGIN
  WAITFOR DELAY '00:00:00.010'
END

Но кроме deadlock_а ничего не получил
Msg 1205, Level 13, State 56, Line 2
Transaction (Process ID 59) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Вопросы:
1. Как вообще могла произойти ошибка "Invalid object name 'dbo.syn_test_1'", если транзакция с DELETE,CREATE отработала без сбоев.
2. DeadLock тоже не приемлем - что можно сделать с учетом того, что только все synonym_ы или ни одного должны быть заменены ?
27 сен 12, 14:13    [13232270]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Greenhorn
Т.к. необходимо заменить все synonym_ы одновременно, то команды DELETE, CREATE выполняются в одной транзакции.

Так случилось, что в момент выполнения пункта 2 в одной из БД проходила интенсивная работа и synonym_ы были успешно пересозданы через полтора часа.
Если пункт "необходимо заменить все одновременно" является необходимым требованием, то это ошибка проектирования.
Процесс (в самом общем смысле) не может быть декларативным условием. И для него нельзя ставить требования. Типа, обязан резать сутки пополам, или ещё что-то подобное. Только структура данных должна позволять делать запросы на определённый временной разрез данных. Это ключевое.

Для чего вы меняете синонимы на новые снапы. Очевидно только для одного, чтобы потом поменять что-то (в справочниках), которое уже никак не отразится на текущие процессы. Но до этого момента вы не можете ничего менять.
Поэтому, вы спокойно можете менять каждый снап вне транзакции (хоть параллельно), и как только все снапы будут изменены, вы можете менять данные (которое уже не отразится).

Greenhorn
Но при этом часть запросов свалилась со следующим сообщением (пример):
Msg 208, Level 16, State 1, Line 3
Invalid object name 'dbo.syn_test_1'.
Как вообще могла произойти ошибка "Invalid object name 'dbo.syn_test_1'", если транзакция с DELETE,CREATE отработала без сбоев.
Хм, а это интересно, видимо надо регать баг на connect.
27 сен 12, 17:49    [13234426]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Greenhorn
Member

Откуда:
Сообщений: 311
Mnior
Greenhorn
Т.к. необходимо заменить все synonym_ы одновременно, то команды DELETE, CREATE выполняются в одной транзакции.

Так случилось, что в момент выполнения пункта 2 в одной из БД проходила интенсивная работа и synonym_ы были успешно пересозданы через полтора часа.
Если пункт "необходимо заменить все одновременно" является необходимым требованием, то это ошибка проектирования.
Процесс (в самом общем смысле) не может быть декларативным условием. И для него нельзя ставить требования. Типа, обязан резать сутки пополам, или ещё что-то подобное. Только структура данных должна позволять делать запросы на определённый временной разрез данных. Это ключевое.

Для чего вы меняете синонимы на новые снапы. Очевидно только для одного, чтобы потом поменять что-то (в справочниках), которое уже никак не отразится на текущие процессы. Но до этого момента вы не можете ничего менять.
Поэтому, вы спокойно можете менять каждый снап вне транзакции (хоть параллельно), и как только все снапы будут изменены, вы можете менять данные (которое уже не отразится).

К сожалению с точностью да наоборот.
Попробую более подробно рассказать как я докатился до жизни такой.
Первоначально задача стояла (и стоит) так:
Есть несколько инстансов на разных серверах одного кластера с однотипными базами, в которые идет загрузка 24х7.
В процессе загрузки проводится дополнительная обработка на основе справочной информации, которая распространяется с помощью snapshot replication из внешней системы на каждый инстанс в одну отдельную справочную базу.
Технологически процесс ведения справочной информации заключается в следующих действиях.
В течении раб. дня операторы вносят инфу во внешнюю систему. Далее, "ответственная" группа специально обученных сотрудников, проверяет введенную информацию и по кнопке (это важно) или по заданию генерится и распространяется snapshot.
Далее начинаются приключения.
Первоначально я просто использовал стандартные настройки репликации для таблиц "Action is name is in use":
"Drop existing object and create a new one"
При водит к тому, что запросы периодически падают с ссобщением, что таблицы не существует.
"Truncate all data in the existing object"
При водит к тому, что запросы не падают, НО выдают неверные данные, т.к. в момент выполнения справочная таблица пуста.
"Delete data. If article has a row filter, delete only data that matches the filter."
Не использовал, т.к. фильтров нет.
"Keep existing object unchanged".
Не использовал, т.к. как раз object то и нужно поменять.
Ну и в качестве бонуса - периодической падение репликации по разным причинам, связанных с блокировками.
Конечно, репликация перезапускается, вот только один раз такой сбой привел к тому, что часть справочных таблиц конкретно покривела.
----
Все это натолкнуло на мысль использовать snapshot справочной БД и synonym_ы.
Т.е. после репликации, которая теперь пролетает со свистом без каких либо проблем запускается скрипт, который стартует Job.
В Job_е создается новый snapshot справочной БД и идет поиск synonym_ов по все рабочим БД.
Далее для каждой БД в одной транзакции идет пересоздание synonym_ов. Требуется поменять все synonym_ы одновременно, т.к. справочне таблицы имеют PK,FK и если менять synonym_ы по одному, то есть не нулевая вероятность нарваться на кривыую выборку...
----
Все эти проблемы, конечно же решит регламентное окно (кстати оно имеется).
Вот только пресловутая кнопка, которую могут нажать в любое врем и по несколько раз на дню, ставит крест на всех регламентах.
Отобрать/запретить кнопку не представляется возможным

Может я, конечно, изобретаю велосипед с квадратными колесами.
Может я чего то не понимаю/не знаю.
Очень надеюсь на Ваши предложения по выходу из такой ситуации, с учетом того, что кнопку трогать нельзя.
1 окт 12, 11:06    [13248047]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
invm
Member

Откуда: Москва
Сообщений: 9724
Почему именно snapshot-репликация?
1 окт 12, 11:17    [13248142]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Greenhorn
Member

Откуда:
Сообщений: 311
Greenhorn,

Во, щас кнопку топтанули и опять сбой.
Вот только что-то совсем крышу сносит - у меня ведутся логи выполнения запросов:
[Время создания запроса] [Время начала его выполнения] [Время завершения выполнения]
2012-10-01 11:05:09.203 2012-10-01 11:05:09.250NULL
2012-10-01 11:15:14.5202012-10-01 11:15:14.6072012-10-01 11:17:16.450

Вторая строка о запросе который свалился с ошибкой. А вот первый запрос продолжает работать, хотя и запустился ранее
Msg 208, Level 16, State 1, Line 3
Invalid object name 'dbo.syn_test_1'.

Что происходит
1 окт 12, 11:32    [13248252]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Greenhorn
Member

Откуда:
Сообщений: 311
invm
Почему именно snapshot-репликация?

Выбрана как наиболее простая.
1 окт 12, 11:33    [13248262]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
invm
Member

Откуда: Москва
Сообщений: 9724
Greenhorn
Выбрана как наиболее простая.
Классный критерий
Какой процент изменений в справочной информации генерирует "В течении раб. дня операторы вносят инфу во внешнюю систему"?
1 окт 12, 11:53    [13248432]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Greenhorn
Member

Откуда:
Сообщений: 311
invm
Greenhorn
Выбрана как наиболее простая.
Классный критерий
Какой процент изменений в справочной информации генерирует "В течении раб. дня операторы вносят инфу во внешнюю систему"?

Под 80%. Но причем тут кол-во процентов.
Задача в том, чтобы обновить всю справочную информацию за "один раз".
Т.к. часть справочной информации, и довольно большая, вводится задним числом, а количество загружаемой 24х7 информации - огромно (сотни млн. записей), то чем реже будет запускаться процесс "корректировки" ранее загруженных данны, тем лучше.
Это, кстати, еще один довод в пользу snapshot репликации.
1 окт 12, 12:12    [13248611]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
invm
Member

Откуда: Москва
Сообщений: 9724
Greenhorn
Под 80%. Но причем тут кол-во процентов.
При том, что это один из критериев выбора типа репликации.
1 окт 12, 13:18    [13249108]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Greenhorn
24х7 проводится операции и их обработка на основана на справочниках
"ответственная" группа по кнопке/заданию распространяет обновлённые (на 80%) справочники
Мне кое-что непонятно:

1. Операции (загрузки) идут потоком, а справочные данные сильно изменены, поэтому операции сделанные после выставления (13.43.50) будут совершенно другими. Но если "ответственный" чихнул вылили на себя кофе и поэтому выставил на 3 минуты позже, поэтому все те сотни операций, которые прошли за эти 3 минуты совершенны совсем по другому (с другим результатом).
Это нормально?

2. Некоторые операции проводятся в несколько запросов и TIL стоит RC. Получается что операции неконсистивны, один запрос в транзакции видит одни справочные данные, а другой другие, что нарушает целостность.
Это нормально?

Не получится выставить всё целиком в принципе.
Дедлок очевиден и правильно что возникает и такое будет всегда при любых подходах.
Вы максимум что можете сделать, так поставить процессу выставления опцию:
SET DEADLOCK_PRIORITY LOW;
И делать в цикле до опупения, пока не пропихнёте.

Но лучше сделать централизованный объект или логическое свойство (дата), о котором я писал выше. И тогда не надо выёживаться и делать неправильную репликацию.
1 окт 12, 13:55    [13249390]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Greenhorn
Member

Откуда:
Сообщений: 311
invm
Greenhorn
Под 80%. Но причем тут кол-во процентов.
При том, что это один из критериев выбора типа репликации.

Хорошо.
Предложите тип репликации отвечающий требованиям технологического процесса:
1. Синхронизация справочной информации по "кнопке" после проверки ее группой "ответственных" работников.
2. Минимизация количества корректирующих процессов для ранее загруженных данных
Подробне см. 13248047
1 окт 12, 14:09    [13249499]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
1й1
Guest
на мой взгляд транзакционная репликация лучше подойдет для этой задачи.
1 окт 12, 14:25    [13249619]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
invm
Member

Откуда: Москва
Сообщений: 9724
Greenhorn,

Я где-то писал, что у вас выбран неверный тип репликации?
Если меняется 80% данных, то снепшот-репликация вполне применима.

Вам что в итоге нужно: обеспечить пересоздание синонимов как единую операцию или справочную БД на подписчиках в логически целостном состоянии?
1 окт 12, 14:38    [13249709]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Greenhorn
Member

Откуда:
Сообщений: 311
Mnior
Greenhorn
24х7 проводится операции и их обработка на основана на справочниках
"ответственная" группа по кнопке/заданию распространяет обновлённые (на 80%) справочники
Мне кое-что непонятно:

1. Операции (загрузки) идут потоком, а справочные данные сильно изменены, поэтому операции сделанные после выставления (13.43.50) будут совершенно другими. Но если "ответственный" чихнул вылили на себя кофе и поэтому выставил на 3 минуты позже, поэтому все те сотни операций, которые прошли за эти 3 минуты совершенны совсем по другому (с другим результатом).
Это нормально?

Скорее неизбежное зло.
80% подвержена только одна из самых основных справочных таблиц, в которой хранятся диапазоны значений и время их жизни. Такое кол-во изменений - результат работы не операторов (который вносят не более 2,3 сотни новых значений), а процедуры оптимизатора, которая склеивает/разбивает диапазоны. Отсюда выходит, что при малых операторских корректировках, меняются до 80% записей.
Уже загруженный поток данных на 95% останется корректен, а оставшиеся 5% необходимо скорректировать, что и происходит после репликации.

Mnior
2. Некоторые операции проводятся в несколько запросов и TIL стоит RC. Получается что операции неконсистивны, один запрос в транзакции видит одни справочные данные, а другой другие, что нарушает целостность.
Это нормально?

Не получится выставить всё целиком в принципе.
Дедлок очевиден и правильно что возникает и такое будет всегда при любых подходах.
Вы максимум что можете сделать, так поставить процессу выставления опцию:
SET DEADLOCK_PRIORITY LOW;
И делать в цикле до опупения, пока не пропихнёте.

Собственно на это и надеялся. Т.к. "окна" в загрузке как правило есть - в среднем транзакция по пересозданию synonym_ов не весит более 10 минут.
По поводу того, что разные запросы видят разные справочные данные - это нормально только в том случае, если эти справочные данные консистентны по отношению друг к другу (т.е. все synonym_ы смотрят на одни snapshot).
А об остальном позаботится "корректор" см. выше.

Mnior
Но лучше сделать централизованный объект или логическое свойство (дата), о котором я писал выше. И тогда не надо выёживаться и делать неправильную репликацию.

А как правильно по Вашему ?
Правильно ли я понял, что под "логическим свойством дата" Вы подразумеваете дату "модификации" ?
Или это свойство относится к самой справочной информации ? - Так это уже имеется. И чем это может помочь уже загруженным данным, если справочная инфа меняются задним числом ?
1 окт 12, 14:46    [13249763]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Greenhorn
Member

Откуда:
Сообщений: 311
invm
Greenhorn,

Я где-то писал, что у вас выбран неверный тип репликации?
Если меняется 80% данных, то снепшот-репликация вполне применима.

Вам что в итоге нужно: обеспечить пересоздание синонимов как единую операцию или справочную БД на подписчиках в логически целостном состоянии?

Совершенно верно.
Собственно этого я и пытался добиться выполняя пересоздание всех синонимов в одной транзакции для одной БД.
При тестировании все было просто замечательно. А на практике вылезли подводные камни 13232270
1 окт 12, 14:49    [13249796]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Greenhorn
Member

Откуда:
Сообщений: 311
invm
Вам что в итоге нужно: обеспечить пересоздание синонимов как единую операцию или справочную БД на подписчиках в логически целостном состоянии?

Прошу прощения, не совсем точно ответил.
Да, мне нужно обсепечить логическую целостность справочных БД на подписчиках.
Для этого я и создаю database snapshot после успешной snapshot репликации.
А для того, чтобы один запрос в котором используется более одного синонима был "согласован" - необходимо добится
пересоздания синонимов за "одну единую операцию".
1 окт 12, 15:08    [13249969]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Greenhorn
в основной справочной таблице хранятся временные диапазоны значений
оперативные данные (где-то 5%) необходимо скорректировать после репликации
Правильно ли я понимаю, что:
Вы делаете замену некоторых вторичных вычислений по операциям задним числом?
Вы анализируете ("оптимизатором") проведённые операции, которые были совершены до "применения" справочников и исправляете их (вторичные данные) ?

Тогда вопрос: Задлянафига вообще делать эти вычисления до "применения" справочников ?

Может пусть при операциях (закачек) делают тупо ввод данных, без подсчёта (хрен знает что у вас там проводки/результирующие итоговые данные или т.п.). А после "применения" справочников произвести вычисления для всех операций, точнее во время "закрытия" операционного периода.
Greenhorn
а процедуры оптимизатора, которая склеивает/разбивает диапазоны. Отсюда выходит, что при малых операторских корректировках, меняются до 80% записей.
Это я не совсем понял.
Справочные данные подгоняются (подтасовываются) под операции, чтобы в итоге изменений было минимум?
Вы там чем занимаетесь?
Greenhorn
По поводу того, что разные запросы видят разные справочные данные - это нормально только в том случае, если эти справочные данные консистентны по отношению друг к другу (т.е. все synonym_ы смотрят на одни snapshot).
А об остальном позаботится "корректор" см. выше.
Вы немного недопонимаете.
Вот началась транзакция некоторой операции. Она состоит их двух запросов (INSERT/UPDATE + INSERT/UPDATE). Оба запроса используют справочники.
Так вот, допустим что так попало что ровно меду двумя запросами произошла подмена всех справочников. Получается первая часть операции прошла со старыми данными, а вторая с новыми. Не рыба, ни мясо.

Если "корректор" будет считать что операция правильная, ибо закончила работать с новыми справочниками, то это ошибка.
Если "корректор" будет считать что операция не правильная, ибо начала работать со старыми и будет вычислять дельту согласно тому что она полностью работала со старыми данными - то это ошибка.
Если корректор плюёт на то как данные были подсчитаны и тупо их пересчитывает и перекрывает сверху, то тут две ошибки:
1. То что важно атомарно выставлены справочники или нет - это неважно
2. То что операции вообще делают вычисления (на основании неподтвержденных справочников).

Greenhorn
И чем это может помочь уже загруженным данным, если справочная инфа меняются задним числом ?
Уже ничем. Стратегия "задним числом" определяет перенос вычислений "на потом", когда все данные "подтвердятся".
1 окт 12, 16:23    [13250786]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
invm
Member

Откуда: Москва
Сообщений: 9724
Greenhorn,

Можно обеспечить и логическую целостность и избавиться от снепшотов.

Для этого на подписчиках включается RCSI.

На издателе:
- создаются копии рабочих таблиц и реализуется любая система отслеживания изменений рабочих таблиц;
- настраивается транзакционная репликация таблиц-копий;
- по "нажатию кнопки" или по расписанию, все накопленные изменения рабочих таблиц в одной транзакции применяются к таблицам-копиям.
1 окт 12, 16:38    [13250930]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
invm, и это избавит от DeadLock ?
1 окт 12, 17:10    [13251229]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
invm
Member

Откуда: Москва
Сообщений: 9724
Mnior,

Нет синонимов -- нет дедлока.
1 окт 12, 17:18    [13251293]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
invm
Есть изменение рабочих таблиц в одной транзакции
Значит возможны DeadLock-и.
Какая разница. SYNONYM - просто блокирует объекты целиком в определённом порядке, а изменения - строки/страницы в определённом порядке.
Но вероятность может сильно уменьшится.

Логическая проблема никуда не делась.
1 окт 12, 17:25    [13251371]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
invm
Member

Откуда: Москва
Сообщений: 9724
Mnior
invm
Есть изменение рабочих таблиц в одной транзакции
Это где я такое написал?
И вообще, я пока слабо понимаю о чем вы. О каких дедлоках речь?
1 окт 12, 17:43    [13251559]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
invm, 13250930 - последнее предложение.
invm
- по "нажатию кнопки" или по расписанию, все накопленные изменения рабочих таблиц в одной транзакции применяются к таблицам-копиям.

Дедлоки в первом же посте.
Возникают они не из-за слова SYNONYM.
А из-за порядка наложения локов.

Что SYNONYM что UPDATE/MERGE - те же яйца, только в профиль.
1 окт 12, 18:18    [13251821]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
invm
Member

Откуда: Москва
Сообщений: 9724
Mnior, ИМХО "Есть изменение рабочих таблиц в одной транзакции" и "все накопленные изменения рабочих таблиц в одной транзакции применяются к таблицам-копиям." имеют разный смысл.

Но ок, немного перефразирую -- все накопленные изменения рабочих таблиц одной транзакцией применяются к таблицам-копиям.

Дедлоки из первого поста уходят в небытие вместе с причиной их породившей -- синонимами. Система приходит к виду: один писатель (репликационный агент) и много читателей в режиме RCSI. Никаких промежуточных служебных объектов не требуется.
1 окт 12, 19:27    [13252159]     Ответить | Цитировать Сообщить модератору
 Re: alter synonyms  [new]
Greenhorn
Member

Откуда:
Сообщений: 311
Mnior
Правильно ли я понимаю, что:
Вы делаете замену некоторых вторичных вычислений по операциям задним числом?
Вы анализируете ("оптимизатором") проведённые операции, лкоторые были совершены до "применения" справочников и исправляете их (вторичные данные) ?

Тогда вопрос: Задлянафига вообще делать эти вычисления до "применения" справочников ?

Может пусть при операциях (закачек) делают тупо ввод данных, без подсчёта (хрен знает что у вас там проводки/результирующие итоговые данные или т.п.). А после "применения" справочников произвести вычисления для всех операций, точнее во время "закрытия" операционного периода

Ответ:
Поток данных, который обогащается на основе справочной информации - огромен, и данные необходимо ежедневно предоставлять разным OLAP системам. Отсюда отложить обработку на более поздний период (когда справочники устаканятся), не представляется возможным.
Разброс справочной информации, внесенной задним числом, достататочно большой, но, в результате анализа изменений, процент изменений уже загруженной информации не превышает 5%. Более того, OLAP системы даже не учитывают данные изменения (на сколько мне известно).
Mnior
Greenhorn
а процедуры оптимизатора, которая склеивает/разбивает диапазоны. Отсюда выходит, что при малых операторских корректировках, меняются до 80% записей
Это я не совсем понял.
Справочные данные подгоняются (подтасовываются) под операции, чтобы в итоге изменений было минимум?
Вы там чем занимаетесь?

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

Mnior
Вы немного недопонимаете.
Вот началась транзакция некоторой операции. Она состоит их двух запросов (INSERT/UPDATE + INSERT/UPDATE). Оба запроса используют справочники.
Так вот, допустим что так попало что ровно меду двумя запросами произошла подмена всех справочников. Получается первая часть операции прошла со старыми данными, а вторая с новыми. Не рыба, ни мясо.

Входной поток - только INSERT
"Корректировка" - только UPDATE.
Т.е. нет "двух запросов".

P.S. deadlock вознник только при неудачной попытке повторить ошибку 208 на тестовых данных в тестовой базе.
На пром. системе таких ошибок пока не возникало. Я с самого начала не исключал возможность возникновения deadlock_ов, но они мне не страшны, т.к. в системе уже предусмотрена защита от подобных неприятностей (повтор запроса через паузу).
1 окт 12, 20:06    [13252251]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить