Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 3 [4] 5 вперед Ctrl→ все |
Glory Member Откуда: Сообщений: 104760 |
А вы наверное всегда пишите супер код и ваши запросы всегда выдают правильные данные. Даже если исходные данные направильные. А вокруг скачут розовые пони. |
||
8 авг 14, 11:18 [16415994] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Вот вам реальная задача Источник данных доступен только с 2х часов ночи Загрузка должна быть завершена до 3х часов ночи MERGE работает 30 минут I/U/D работают 45 минут В 2:29 MERGE и I/U/D падают с ошибкой нарушения уникальности. Вопрос - какой из методов имеет больший шанс закочить загрузку до 3х часов ? |
||
8 авг 14, 11:24 [16416050] Ответить | Цитировать Сообщить модератору |
sphinx_mv Member [заблокирован] Откуда: Сообщений: 1672 |
Работать с данными не имея ни малейшего представления о их структуре и взаимосвязях - верх идиотизма.
![]() А даже если и так... Разве замена таблиц на "представления с ограниченными правами" отменяет необходимость знания их структуры и взаимосвязей? Так и хочется ("сугубо для истории") записать, что Вы пишете запросы неизвестно КАК неизвестно ИЗ чего и неизвестно ДЛЯ чего... При этом (почему-то) умудряетесь предъявлять претензии на получение плохо понятных Вам и трудно объяснимых с Вашей точки зрения результатов. К тому же, если в реальном мире реальная задача того требует, получить ЛЮБЫЕ права на "голые" таблицы не составляет проблемы - отношение к раздаче прав для "автоматов" (а это как раз такая задача) несколько отличаются от раздачи прав для "живых" пользователей.
|
||||||||||
8 авг 14, 11:40 [16416165] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Офигеть. Вы даже не можете отличить примера от реального запроса. Т.е. если вам привести реальный запрос, то вы бы сразу сказали - ну вот тут у вас в 17ой строке не хватает условия сравнения, потому что если в таблице1 будет запись с комбинацией данных a,c, 10 в полях f1, f2, f3 а в таблице2 при этом окажется запись с комбинацией данных 10.25, 0xAA в полях f6, f10, то при INSERT будет нарушен уникальный ключ ? Ну тогда вот - давайте, покажите свой класс. расскажите, почему тут дубликаты могут возникнуть INSERT INTO DWH.T0303_ACCOUNT_STATUS_HISTORY ( Account_Nbr, Account_Nbr_Modifier, Acct_Status_Start_Date, Acct_Status_Type_Code, Acct_Status_End_Date ) SELECT tn.Account_Nbr, tn.Account_Nbr_Modifier, tn.Acct_Status_Start_Date, tn.Acct_Status_Type_Code, tn.Acct_Status_End_Date FROM OSA.H_NewHistory tn LEFT JOIN DWH.T0303_ACCOUNT_STATUS_HISTORY t ON tn.Account_Nbr=t.Account_Nbr AND tn.Account_Nbr_Modifier=t.Account_Nbr_Modifier AND tn.Acct_Status_Start_Date=t.Acct_Status_Start_Date AND (tn.Acct_Status_End_Date=t.Acct_Status_End_Date or (tn.Acct_Status_End_Date is null AND t.Acct_Status_End_Date is null)) AND (tn.Acct_Status_Type_Code=t.Acct_Status_Type_Code or (tn.Acct_Status_Type_Code is null AND t.Acct_Status_Type_Code is null)) WHERE (t.Account_Nbr is null AND t.Account_Nbr_Modifier is null) and NOT (tn.Acct_Status_Type_Code is null) |
||
8 авг 14, 11:50 [16416250] Ответить | Цитировать Сообщить модератору |
Ivan Durak Member Откуда: Minsk!!! Сообщений: 3646 |
в такой нестабильной схеме однозначно правильная последовательность действия такая 1. Скопировать bulk insert-om данные из источника в чистый stage максимально быстро и максимально надежно. 2. Делаем из стейджа мерж в приемник. 3. Profit |
||||
8 авг 14, 11:51 [16416251] Ответить | Цитировать Сообщить модератору |
sphinx_mv Member [заблокирован] Откуда: Сообщений: 1672 |
|
||||
8 авг 14, 11:56 [16416300] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Причем здесь это Я же не сказал, что источник доступен только до 3х часов. Это загрузка должна быть завершена до 3х часов. А начинать ее нельзя раньше 2х Стейдж здесь может только влиять на скорость обнаружения/исправления исходных данных, но не скорость Но вы можете принять условие задачи, что в 2 часа делается выборка из источника в стейдж Все остальное - время работы каждого метода, время падения - остается тоже самое |
||
8 авг 14, 11:57 [16416308] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Покажите класс. Там выше реальный код запроса. |
||
8 авг 14, 11:57 [16416316] Ответить | Цитировать Сообщить модератору |
sphinx_mv Member [заблокирован] Откуда: Сообщений: 1672 |
Сугубо потому, что в случае падения а) нужно выявить точное место (в исходных данных!) возникновения нарушения уникальности, б) пофиксить его и в) повторить процедуру, молясь при этом, что не будет очередного глюка. И, кстати, использование в рабочем окружении отвратительно проверенного и плохо работающего решения - как минимум, не серьезно. На самом деле исключение падений решается СУГУБО за счет приведения исходных данных (в "оригинальных" таблицах или через запросы к ним) в постоянно гарантированное консистентное состояние. |
||||
8 авг 14, 11:59 [16416327] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Да конечно
Выявили. Время 2-31
Пофиксили. Время 2-35
Запустили MERGE, который работает 30 минут. Время окончания 3-05 Запустили I/U/D c _упавшего_ шага. Ориетировочно время работы 45 -29 = 16 минут. Время окончания 2-51 |
||||||||
8 авг 14, 12:03 [16416363] Ответить | Цитировать Сообщить модератору |
sphinx_mv Member [заблокирован] Откуда: Сообщений: 1672 |
А просто посмотреть по значениям каких полей в таблице-назначении может возникнуть нарушение уникальности, слабо?! "Рукалицо"... |
||||
8 авг 14, 12:08 [16416419] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Да А вы подтвержадете, что можете это сделать по тексту запроса? |
||
8 авг 14, 12:10 [16416428] Ответить | Цитировать Сообщить модератору |
sphinx_mv Member [заблокирован] Откуда: Сообщений: 1672 |
![]()
![]() Все выполненные изменения необходимо откатывать и повторять по-новой. С дополнительными затратами времени... ЗЫ. Все как-то стесняюсь спросить... Ваши "реальные задачи" все такие? |
||||||||
8 авг 14, 12:31 [16416602] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Упертость ваша зашкаливает. Специально для вас повторяю В 2 часа происходит выгрузка источника в стейдж таблицу. Которая далее не меняется. Все остальныке условия задачи остаются такими же
Это вы сами решили, или вам кто-то сказал. Какой реальный объем данных из скольки источников вы загружали ? Делали ли вы это в жестко заданный временной интервал ? |
||||
8 авг 14, 12:37 [16416643] Ответить | Цитировать Сообщить модератору |
sphinx_mv Member [заблокирован] Откуда: Сообщений: 1672 |
Но если Ваши религизные убеждения не позволяют этого сделать, наука тут бессильна... ![]() |
||||
8 авг 14, 12:48 [16416730] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Это представление.
Что вам даст текст представления ? На простом примере вы как то справились без DDL А тут слабо ? |
||||
8 авг 14, 12:51 [16416751] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
А что вам скажет главбух, если он вообще не сможет ничего посчитать ? Потому что вы все время перезапускаете упавший процесс "С дополнительными затратами времени." |
||
8 авг 14, 12:55 [16416775] Ответить | Цитировать Сообщить модератору |
sphinx_mv Member [заблокирован] Откуда: Сообщений: 1672 |
Кто запрещает проверять уникальность сразу в stage таблице??? Или вобще ДО загрузки в нее??? Упс! Совершенно нескромный вопрос... Вы вообще в каком месте выявленные ошибки устраняете - в "самых исходных" данных или только в stage-таблице??? И как у Вас смотрят на ситуации, когда архивные данные не соответствуют оперативным? И что произойдет с Вашими отчетами, когда возникнет необходимость перезаливки данных (по какой-нибудь причине через некоторое время "после того как")?
И если Вы согласны вытерпеть все то, что с Вами сделает главбух после сдачи в налоговую квартального отчета, полученного на основе загруженных Вами данных - Вы вполне имеете на это право... Но мои сексуальные предпочтения и фантазии настолько далеко не распрастраняются.
|
||||||||||
8 авг 14, 13:10 [16416878] Ответить | Цитировать Сообщить модератору |
sphinx_mv Member [заблокирован] Откуда: Сообщений: 1672 |
Актуально... Факт... Вот только, Вам уже неоднократно как бы намекалось, что бороться нужно не с симптомами, а с причиной... Нарушение уникальности - симптом. Неконсистентность загружаемых данных - причина. |
||||
8 авг 14, 13:12 [16416898] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Элементанрая логика Потому что стейдж таблица должна быть полной копией того, что выгрузили. А не частью.
И там и там. Просто не одновременно. Потому, что где точно источник физически хранит эти данные, известно админу источника
Ваше горе, что вы не можете понять, что исправив стейдж таблицу, я загружу правильные данные. И загружу их быстрее. Потому что начну загрузку не с начала.
Боюсь что вас будут иметь еще до сдачи отчета. Потому вы свой отчет вообще не получите. Хоть с правильными данынми, хоть с неправильными. |
||||||||
8 авг 14, 13:19 [16416941] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Ой бл*. Ну поставьте вместо 3х ночи, 3 дня. Придирчивый вы мой
И как же вы боритесь с причиной. Расскажите. |
||||
8 авг 14, 13:20 [16416959] Ответить | Цитировать Сообщить модератору |
sphinx_mv Member [заблокирован] Откуда: Сообщений: 1672 |
Танец "уж на сковородке" у Вас очень классно получается.
Во-вторых, общее представление о DDL в простом примере, на котрый Вы ссылаетесь, все же имелось... Ну, и в-третьих... Вам как бы уже намекалось, что решение задачи без полного анализа исходных требований и условий - нонсенс. Уточнение DDL используемого представления, уточнение DDL таблиц, которые в этом представлениии используются - это все еще анализ задачи... Надеюсь, но не особо, что хоть с этим Вы не будете спорить... |
||||||||
8 авг 14, 13:27 [16417003] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Я так понимаю вы ни разу на слышали про Представительский уровень. Когда таблицы специально скрывают за витринами. Жаль, что у вас пробел в этой теме.
Родной, это реальная жизнь. Никто не обещал тебе права Бога на все, что захочешь
Разумеется оно есть. Вопрос только в доступности DDL
Ой как много условий. Как-то все больше становится похоже на извивание на сковородке. Вы сами то что прямо так просматриваете все объекты и запросы во всех базах/серверах ? Может быть вы их еще и тестируете до установки ? Да еще на реальных данных тестируете ? |
||||||||
8 авг 14, 13:33 [16417061] Ответить | Цитировать Сообщить модератору |
sphinx_mv Member [заблокирован] Откуда: Сообщений: 1672 |
![]() Исправление неконсистентных исходных данных, которые приводят к нарушению уникальности, Вы с таким подходом ОБЯЗАНЫ выполнять на этапе ДО загрузки в stage. Что автоматически тянет за собой перезаливку stage в случае сбоев. Что явно добавляет секусуальности в решение поставленной задачи...
А что произойдет, если при исправлении "самых исходных" данных будут допущены другие ошибки? Правильный ответ будет состоять из нескольких этажей отборного мата. И это - в лучшем случае... Кстати... Не очень завидую админу "источника", хоть у него и могут быть "варианты"...
![]() Вас не смущает тот факт, что я ЗНАЮ причину, и, соответственно, имею ненулевую вероятность в худшем случае перевести стрелки на реального виновника получения неверных данных для отчет, а в лучшем случае - получу время на выявление и устранение причины возникновения проблем. При вмяняемом руководстве (а другого не держим) "ненулевой" уровень одначает "предельно близко к единице"... Обращаю внимание: устранение причины возникновения проблемы означает "всерьез и надолго" - практически, "насовсем". |
||||||||||||||||
8 авг 14, 13:54 [16417227] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Если я что и обязан, то это загрузить правильные данные до 3х часов. Потому что с 3хчасов еще куча загрузок и рассчетов будет ждать эти данные А стейдж нужен(еще раз повторяю) для того, что бы точно знать, что предоставлял источник именно в тот момент времени.
Т.е. исправленные в стейдже данные уже не являеются правильными ? Нужно обязательно исправить источник и повторно загрузить вообще все данные ? Мне вот интересно, вы когда книгу читаете и видите опечатку, вы ждете, пока выйдет новое издание книги и начинаете читать ее сначала ?
Это вы уже придумали. В стейдже правятся ошибочные данные. Т.е. данные, которые не загрузились. А те которые загрузлись, не правяться. И не грузяться заново. Потому что с ними все хорошо. А Все изменения источника, сделанные после текущей загрузки, попадают в следующую загрузку. И если источник не успеет исправить дубликаты, то я опять исправлю стейдж и таки загружу данные. И вы будете куковать и объяснять своим главбухам, что команда MERGE - это же прирост производительности и уменьшение кода. Просто нерадивый источник все портит.
Во-во, я понял. Перевести стрелки - это именно то, что надо. |
||||||||
8 авг 14, 14:08 [16417345] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 3 [4] 5 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |