Опять ДБ трабл.

[AgentXXX]

Сиквиляторы и прочие ДБ-маньяки имеющие локально обрабатываемые SSIS, на локально инстальнутом 2005 сиквеле.

Это только у меня такой глюк или это в порядке вещей?

Описуяриваю ситуацию:

На ноуте(2 gb, Turion) локально запускаю из ВС 2005 на выполнение пакетик.Ничего особенного, параметризированная обработка 3х .ксылысы файлов.

Локально взял через линкед сервер, почистил-обработал-трансформнул сгрузил в локальную базу.

Каждый файл по 3-4 шИта, из которых только последний имеет меньше 65к записей, остальные по 65К т.е. под завязку.

Линкуются файлы нормально, выборка бежит по каждому файлу по 15-20 миннут.При перезаписи на сервер в каждом шаге сортинг по дататайму стоит.

И вот тут-то компик дохнет.Конкретно висит мерзавец до 30-45 минут пока данные перекинет дальше.Причём план выполнения показывает гемор именно в сортинге.Неужели сортинг 65К*3 + 30К(45К) записей может вызывать такой глюк?

Кто сталкивался с таким гемором?

Сиквелу мозгов выделил 1 гиг.Может мало?

 

P.S.Со старым добрым ДТС на 2000 такое безобразие мухой летало.

 

P.P.S.Я на работе в такую пору не из-за этого. )))

[Yevgen35]

Вижу новую линку ты уже прикрутил.

Очень рад тебя снова видеть.

 

По твоему вопросу.

Как ты понимаешь я не спец в MSSQL, поэтому подскажу тебе просто путь Джедая.

Вместо того чтобы задавать такие вопросы на подобных форумах, следует сделать следующее.

- Убедится, что ситуация воспроизводима и повторяема.

- Поскольку ваша фирма имеет ( я надеюсь ) купленый официально софт и проплаченную техподержку. То следует оформить TAR( Technical request ) и отправить его службу тех подержки Microsoft.

- Достать в усмерть службу техподержки. Всячески их долбать и напоминать, о себе не позволяя им закрыть подобный request, как неактивный.

Самое главное в этом вопросе пробить первую линию обороны, где сидят в основном одни индусы-придурки, которые даже не читают, то что ты написал.

Из задача просто отфутболить тебя. Здесь требуется очень много терпения и силы воли.

Извини за откровение.

- Получить результат.

 

Результаты подобных действий могут быть следующие:

1. Это фитча.

2. Это баг уже зарегистрированный и к нему есть патч.

3. Это баг, зарегистрированный, и патча к нему нет.

4. Это баг незарегистрированный. Благодаря тебе он будет зарегистрирован и далее п 2 или п 3.

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

6. Проблема никак не связана с ПО СУБД. Такое тоже возможно.

 

Бороздя форумы ты сможешь получить лишь только ответы 1,2,3.

Остальные будут для тебя недостижимы.

 

 

P.S. И незабудь нам отписать свои впечатление от службы подержки Мicrosoft.

Я буду с нетерпением их ждать.

[Warm]

1. Это фитча.

2. Это баг уже зарегистрированный и к нему есть патч.

3. Это баг, зарегистрированный, и патча к нему нет.

4. Это баг незарегистрированный. Благодаря тебе он будет зарегистрирован и далее п 2 или п 3.

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

6. Проблема никак не связана с ПО СУБД. Такое тоже возможно.

 

7. Это баг, зарегистрированный, и патча к нему нет, но профессиональные танцоры с бубнами уже придумали пути обмана сервера

 

Если по делу:

 

Сортинг в Data Flow?

 

Если да, то такой объем проще перекинуть во временную таблицу и отфильтровать запросом. Хотя мне проблемы с этим не встречались. Зато мне встречались ситуации, когда 2 компа отличались по мощности совсем чуть-чуть, но на одном 10Мb XML обрабатывался 20 минут, а на другом - 40 секунд, так что - попробуйте поменять машину

 

Из вашего описания не совсем понятно что и куда, поэтому просто по подробным симптомам найдите описание траблы в инете - наверняка есть, только естественно не на русском, на русском инфы по SSIS почти нет.

[AgentXXX]

Опять туплю.

Спасайте.

SUBJ.

[vladiSib]

я, уже лет 5 как с МССКУЛем не возился. но сразу напрашивается вариант "в лоб" - написать свою функцию. а там уж пусть оно вычисляет, складывает или умножает.

[AgentXXX]

написать свою функцию

Некошерно табличные функции из селекта звать.

 

Ладно, всем спасибо за виртуальную поддержку.

Сделали , проехали, забыли.

Хотелось без цикла, но ..... он рулит.

[jes]

А тем временем

Компания Yahoo утверждает, что ей удалось побить мировой рекорд, создав самую большую и нагруженную базу данных в мире. Объём данных 2 петабайта, нагрузка 24 млрд событий в сутки. Работает под управлением модифицированного PostgreSQL (одно из самых крупных изменений: ориентация на по-колоночное хранение вместо традиционного построчного, что замедляет запись на диск, но обеспечивает большую скорость доступа к данным для аналитических целей)

[softwarrior]

1. Создаем. Восемь было делать влом поэтому всего четыре.

 

CREATE TABLE [dbo].[testdata] (
[id] [int] NULL ,
[data_1] [datetime] NULL ,
[data_2] [datetime] NULL ,
[data_3] [datetime] NULL ,
[data_4] [datetime] NULL 
) ON [PRIMARY]
GO

 

2. Заполняем рандомными датами

 

 
1 2008-01-01 00:00:00.000 2008-03-02 00:00:00.000 2008-05-02 00:00:00.000 2007-05-05 00:00:00.000 
2 2007-05-04 00:00:00.000 2006-03-04 00:00:00.000 2006-08-02 00:00:00.000 2008-04-03 00:00:00.000 
3 2007-04-03 00:00:00.000 2007-07-07 00:00:00.000 2000-01-01 00:00:00.000 2008-04-20 00:00:00.000

 

3. Выбираем максимальный для каждой записи, например,

 

select
case
  when ((data_1>data_2) and (data_1>data_3) and (data_1>data_4)) then data_1
  when ((data_2>data_1) and (data_2>data_3) and (data_2>data_4)) then data_2
  when ((data_3>data_1) and (data_3>data_2) and (data_3>data_4)) then data_3
else data_4
end as MaxDateInRow
from testdata

 

 
2008-05-02 00:00:00.000
2008-04-03 00:00:00.000
2008-04-20 00:00:00.000

 

4. Восьмое поле

 select
1,2,3,4,5,6,7, 
case
  when ((data_1>data_2) and (data_1>data_3) and (data_1>data_4)) then data_1
  when ((data_2>data_1) and (data_2>data_3) and (data_2>data_4)) then data_2
  when ((data_3>data_1) and (data_3>data_2) and (data_3>data_4)) then data_3
else data_4
end as MaxDateInRow
from testdata

 

А по правильному это решается правильным проектированием структуры чтобы потом не лопатить данные. Например, триггер при инсерте/апдейте обновляет определенное поле в строке - записывает максимальную дату в строке.

[AgentXXX]

Мне показалось, что так будет кошернее.

Это кусок черновика.

..............
declare @cur_table table( caseID varchar(50), d datetime);
..............
declare f cursor scroll local
for select caseID from @t
open f
    while 1=1
            begin
                fetch next from f 
                    into @fn 
                        insert into @cur_table
                                        select caseID, none_d        d from  @t where caseID=@fn
                                        union all
                                        select caseID, simple_d      d from  @t where caseID=@fn
                                        union all
                                        select caseID, complex_d     d from  @t where caseID=@fn
                                        union all
                                        select caseID, man_d  d from  @t where caseID=@fn
                                        union all
                                        select caseID, pol_d   d from  @t where caseID=@fn
                                            --select caseID,  max(d) from @cur_table group by caseID
                         --update @t set inv_d=( select max(d) from @cur_table where @t.caseID=@cur_table.caseID)
                            
if @@fetch_status <> 0  break
end
close f
deallocate f

select caseID, cast(convert(char(8), max(d), 112) as int) d into #r from @cur_table group by caseID

 

ПыСы.Работает как надо.

[softwarrior]

Мне показалось, что так будет кошернее.

 

Если посмотреть план выполнения запроса, то окажется, что курсор и юнион кушают лишние ресурсы...

[Yevgen35]

А тем временем

Не верю.

Причина простая.

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

 

Напомнило.

"Да я, если хотите знать авианосец потопить могу, если конечно повезет"(с)

[AgentXXX]

курсор и юнион

Курсор да, юнион не очень.А шо делать?

Есть решение лучше?Давай, я завтра перекину.

[jes]

Не верю.

На почитай исходник новости, может там и действительно пожертвовали чем-нибудь.

[Yevgen35]

На почитай исходник новости, может там и действительно пожертвовали чем-нибудь.

Ага, теперь понятно откуда этот спам.

 

Оригинал на английском

Далее с него по ссылке column-based database переходим на Relational database pioneer says technology is obsolete

 

То есть все это отголоски PR-компании column-based database

( Amazon SimpleDB, Apache CouchDB, Google BigTable) и других.

 

 

Ну и наконец, чем мы за это расплачиваемся

Top 10 Reasons to Avoid the SimpleDB Hype

Это собственно то, о чем я говорил в предыдущем моем сообщении.

 

Что касается переделанного PostrgeSQL.

Все равно не верю ибо это не реально.

Поменять механизм хранения данных с row-based на column-based у конкретного продукта - это просто немыслимый объем работы, а это уже новый продукт.

Это все равно, что у Запорожца выбросить все внутренности и поставить все от Порше.

Что в итоге получится? Недоделанный Порше или пальцатый Запорожец.

 

Предположу, что от PostrgeSQL там только анализатор SQL, да собственно это и не важно, главное понять в какую сторону "ветер дует".

[alp]

Мне показалось, что так будет кошернее.

Это кусок черновика.

...

 

ПыСы.Работает как надо.

 

Афигеть! Это типа тебе оракловый GREATEST нужен?