Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Непонятное поведение UNION  [new]
Morfeuz
Member

Откуда: Санкт-Петербург
Сообщений: 51
Имеется MSSQL 2000 и запрос вида:

SELECT CONVERT(char(7),DateDST, 120) as YYYY_MM, GTP_Code, 'Мощность по 13.2' as ResType, AVG(Power) as Power
FROM 
(
SELECT gtpres.GTP_Code, gtpres.DateDST, CAST(MAX(VolFact) as float) as Power
FROM CALENDAR cal
INNER JOIN GTP_Results gtpres
  ON cal.DateDST = gtpres.DateDST AND cal.IntDST = gtpres.IntDST
  AND cal.DayType = 'РАБ'
  AND cal.IntDST IN ('22-23', '21-22', '20-21', '19-20', '18-19', '17-18', '16-17', '15-16', '14-15',
                            '13-14', '12-13', '11-12', '10-11', '09-10',  '08-09', '07-08', '06-07', '05-06')
GROUP BY gtpres.GTP_Code, gtpres.DateDST
) t1
GROUP BY GTP_Code, CONVERT(char(7),DateDST, 120)
UNION
SELECT CONVERT(char(7),DateDST, 120) as YYYY_MM, GTP_Code, 'Суммарная мощность' as ResType, SUM(VolFact) as Power
FROM GTP_RESULTS
GROUP BY GTP_Code, CONVERT(char(7),DateDST, 120)
ORDER BY CONVERT(char(7),DateDST, 120), GTP_Code

Т.е. объединяются результаты двух запросов для удобства дальнейших действий над полученными результатами. Если выполнить отдельно первый запрос, то, например, для одного месяца получим значения:


2009-10 1 Мощность по 13.2 88630.5
2009-10 2 Мощность по 13.2 8087.181818181818
2009-10 3 Мощность по 13.2 64259.272727272728
2009-10 4 Мощность по 13.2 58138.318181818184

Результат выполнения второго запроса отдельно для того же месяца:


2009-10 1 Суммарная мощность 60330516
2009-10 2 Суммарная мощность 5213435
2009-10 3 Суммарная мощность 40161583
2009-10 4 Суммарная мощность 27061879

А вот если выполнить запрос целиком, то получим:


2009-09 1 Суммарная мощность 54203673.0
2009-09 2 Мощность по 13.2 7518.1999999999998
2009-09 2 Суммарная мощность 4269780.0
2009-09 3 Мощность по 13.2 57708.199999999997
2009-09 3 Суммарная мощность 32887296.0
2009-09 4 Мощность по 13.2 44341.666666666664
2009-09 4 Суммарная мощность 24191497.0
2009-10 1 Мощность по 13.2 85843.666666666672
2009-10 1 Суммарная мощность 60330516.0
2009-10 2 Мощность по 13.2 7594.2857142857147
2009-10 2 Суммарная мощность 5213435.0
2009-10 3 Мощность по 13.2 62957.476190476191
2009-10 3 Суммарная мощность 40161583.0
2009-10 4 Суммарная мощность 27061879.0
2009-10 4 Мощность по 13.2 49816.857142857145

Т.е. результаты второго запроса вошли в объединённый набор без изменений, а первого - странным образом модифицировались. Если поменять их местами, картина та же самая :) Где ошибка?
25 ноя 09, 17:35    [7978496]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
iljy
Member

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

во-первых - замените UNION на UNION ALL, незчем лишнюю работу на сервер вешать.
а во-вторых - чего у вас с типами данных?
25 ноя 09, 17:45    [7978566]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Morfeuz
Member

Откуда: Санкт-Петербург
Сообщений: 51
С UNION ALL понял, облегчим ему жизнь

А с типами такая вещь:

CREATE TABLE [GTP_RESULTS] (
	[DateDST] [datetime] NOT NULL ,
	[GTP_Code] [char] (8) COLLATE Cyrillic_General_CI_AS NOT NULL ,
	[IntDST] [char] (5) COLLATE Cyrillic_General_CI_AS NOT NULL ,
	[VolFact] [int] NULL ,
)

CREATE TABLE [CALENDAR] (
	[DateDST] [datetime] NOT NULL ,
	[IntDST] [char] (5) COLLATE Cyrillic_General_CI_AS NOT NULL ,
	[Weekday] [char] (2) COLLATE Cyrillic_General_CI_AS NOT NULL ,
	[DayType] [char] (3) COLLATE Cyrillic_General_CI_AS NOT NULL ,
)
25 ноя 09, 17:50    [7978595]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Glory
Member

Откуда:
Сообщений: 104760
Morfeuz

Т.е. результаты второго запроса вошли в объединённый набор без изменений, а первого - странным образом модифицировались. Если поменять их местами, картина та же самая :) Где ошибка?

И как мы можем проверить это ? Вы предоставите тестовый набор заполнения таблиц, который будет стабильно выдавать такой неправильный результат ?
25 ноя 09, 17:57    [7978655]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Morfeuz
Member

Откуда: Санкт-Петербург
Сообщений: 51
Glory, я-то думал одного взгляда на запрос будет достаточно :) Сейчас сварганю скриптик
25 ноя 09, 18:01    [7978694]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Morfeuz
Member

Откуда: Санкт-Петербург
Сообщений: 51
Мда, если бы это было так просто... Сначала сгенерил тестовые данные от балды, всё работает, всё совпадает. Ладно, думаю, сделаю скрипт на вставку из реальных данных, пусть даже это будет сотня тысяч строк. Вставляю в чистую базу, всё работает, как надо. До чего дошло: в той же базе создаю табличку-двойник с такой же структурой, как у GTP_RESULTS, посредством:
INSERT INTO GTP_RESULTS2 SELECT * FROM GTP_RESULTS
переношу данные, выполняю запрос для новой таблицы - всё хокей!
В общем, со скриптом не получается, бэкап базы выложил сюда (1,27 Мб в архиве). Буду признателен за помощь.
26 ноя 09, 19:51    [7984557]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
iljy
Member

Откуда:
Сообщений: 8711
Morfeuz,
Даже на вашей базе повторить чудеса мне не удалось. У меня
Microsoft SQL Server 2008 (SP1) - 10.0.2746.0 (Intel X86)   Nov  9 2009 16:59:31
   Copyright (c) 1988-2008 Microsoft Corporation  Developer Edition on
 Windows NT 5.1 <X86> (Build 2600: Service Pack 3) 

а результат вашей select @@VERSION огласите пожалуйста. Есть у меня подозрение, что у вас непатченый сервер и функцию AVG кривит на попадающихся в ваших данных NULL.

И еще - у меня результаты выполнения запросов не похожи на выложенные в первом топике даже приблизительно. Так что даже не знаю - что вы считали...
26 ноя 09, 21:20    [7984773]     Ответить | Цитировать Сообщить модератору
 «Ты суслика видишь? — Нет. — И я нет. А он есть!»  [new]
Morfeuz
Member

Откуда: Санкт-Петербург
Сообщений: 51
iljy,
спасибо за интерес!

Итак, по порядку:
1. Результат моей select @@VERSION:
Microsoft SQL Server  2000 - 8.00.2039 (Intel X86)   May  3 2005 23:18:38   
Copyright (c) 1988-2003 Microsoft Corporation  Standard Edition on Windows NT 5.2 
(Build 3790: Service Pack 2) 
Интересно, что только на ней и проявляется. Попробовал ещё на таком сервере:
Microsoft SQL Server  2000 - 8.00.2039 (Intel X86)   May  3 2005 23:18:38   
Copyright (c) 1988-2003 Microsoft Corporation  Personal Edition on Windows NT 5.1 
(Build 2600: Service Pack 3) 
Здесь всё нормально. Вот такая петрушка получается: SQL Server 2000 Standard edition с SP4 глючит на моём запросе, а Personal edition с тем же SP4 нет...
2. А NULLы никак не влияют на расчёт, они первые попали под подозрение. В базе они есть только для периода 2009-11, и даже при их удалении ситуация не меняется.
3. Поскольку данные из производственной базы, то немножко обработал их с помощью RAND перед публикацией в Сети. На неправильность работы UNION это не повлияло :) Если выполнить отдельно первый запрос для тестовой базы, получим (для одного месяца):

2008-01 0 Мощность по 13.2 2247.294117647059
2008-01 1 Мощность по 13.2 6139.2352941176468
2008-01 2 Мощность по 13.2 292.8235294117647
2008-01 3 Мощность по 13.2 5563.7647058823532
2008-01 4 Мощность по 13.2 3851.1764705882351
2008-01 5 Мощность по 13.2 4622.1176470588234
2008-01 6 Мощность по 13.2 6296.8235294117649
2008-01 7 Мощность по 13.2 7084.1176470588234
2008-01 8 Мощность по 13.2 6345.7058823529414
2008-01 9 Мощность по 13.2 4353.588235294118

Результат второго запроса:

2008-01 0 Суммарная мощность 1313698
2008-01 1 Суммарная мощность 4270038
2008-01 2 Суммарная мощность 180517
2008-01 3 Суммарная мощность 3241742
2008-01 4 Суммарная мощность 1907308
2008-01 5 Суммарная мощность 2636129
2008-01 6 Суммарная мощность 3612280
2008-01 7 Суммарная мощность 3346065
2008-01 8 Суммарная мощность 3678013
2008-01 9 Суммарная мощность 2536824

И, наконец, результат запроса с UNION:

2008-01 0 Суммарная мощность 1313698.0
2008-01 0 Мощность по 13.2 2146.0
2008-01 1 Мощность по 13.2 6013.875
2008-01 1 Суммарная мощность 4270038.0
2008-01 2 Мощность по 13.2 281.1875
2008-01 2 Суммарная мощность 180517.0
2008-01 3 Суммарная мощность 3241742.0
2008-01 3 Мощность по 13.2 5299.9375
2008-01 4 Суммарная мощность 1907308.0
2008-01 4 Мощность по 13.2 3283.75
2008-01 5 Суммарная мощность 2636129.0
2008-01 5 Мощность по 13.2 4339.1875
2008-01 6 Суммарная мощность 3612280.0
2008-01 6 Мощность по 13.2 5940.5
2008-01 7 Суммарная мощность 3346065.0
2008-01 7 Мощность по 13.2 6276.5625
2008-01 8 Мощность по 13.2 6050.9375
2008-01 8 Суммарная мощность 3678013.0
2008-01 9 Суммарная мощность 2536824.0
2008-01 9 Мощность по 13.2 4150.5625

В общем, нельзя слепо верить результатам, получаемым от SQL сервера... :( Лучше держать под рукой калькулятор :)

Так и осталось невыясненным, что же такого в этих данных, что сносит крышу серверу напрочь. Причём, интересно, если удалить целиком данные по какому-нибудь из объектов (терпения уже не хватает искать закономерность), начинает считать правильно...
27 ноя 09, 00:56    [7985145]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
iljy
Member

Откуда:
Сообщений: 8711
Morfeuz,
поскольку воспроизвести это мне не удалось (в моем запросе с UNION данные совпадают с вашим без UNION с точностью до 9го знака после запятой), ничего определенного сказать не могу, но если хотите - можем погадать например меня смущает факт, что во втором запросе поле power имеет тип int , а в первом - float. Возможно оптимизатор где-то дурит и округляет данные, причем на Personal он строит другой план и данные уже не округляет. Сравните планы отдельных запросов и запроса с UNION, причем на обоих редакциях. И попробуйте сделать во втором запросе
SUM(CAST(VolFact as float)) as Power
Если я делаю такую замену у себя - результаты начинают совпадать с вашими без UNION полностью.
27 ноя 09, 01:18    [7985164]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Morfeuz
Member

Откуда: Санкт-Петербург
Сообщений: 51
iljy,
явное приведение к типу float, где только можно, тоже было одним из предположений, но на неправильность результата не повлияло.
Похоже, дело действительно в оптимизаторе (картинка прилагается).

К сообщению приложен файл. Размер - 0Kb
27 ноя 09, 01:49    [7985183]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
iljy
Member

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

планы надо выкладывать в виде текста, на картинке мало что видно. Но по тому, что видно - попробуйте OPTION (MAXDOP 1).
27 ноя 09, 01:59    [7985184]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Morfeuz
Member

Откуда: Санкт-Петербург
Сообщений: 51
iljy,
да, с OPTION (MAXDOP 1) всё, как надо. Как жить дальше...
27 ноя 09, 02:12    [7985191]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
iljy
Member

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

с улыбкой;) Переходите на 2005 или 2008. Вообще помнится обсуждали давным-давно глюки 2000 на параллельном выполнении, но я лично не сталкивался и поэтому не вспомнил сразу.
27 ноя 09, 02:24    [7985198]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Microsoft SQL Server 2000 - 8.00.2040 (Intel X86)
May 13 2005 18:33:17
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)


Have the same result as the topic starter (on his data)
OPTION (MAXDOP 1) helps

:(
27 ноя 09, 05:04    [7985238]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
WITHOUT OPTION (MAXDOP 1)


  |--Parallelism(Gather Streams, ORDER BY:([Union1013] ASC, [Union1014] ASC))
       |--Sort(ORDER BY:([Union1013] ASC, [Union1014] ASC))
            |--Concatenation
                 |--Compute Scalar(DEFINE:([Expr1005]=If ([globalagg1025]=0) then NULL else ([globalagg1027]/Convert([globalagg1025]))))
                 |    |--Stream Aggregate(GROUP BY:([Expr1004], [gtpres].[GTP_Code]) DEFINE:([globalagg1025]=SUM([partialagg1024]), [globalagg1027]=SUM([partialagg1026])))
                 |         |--Sort(ORDER BY:([Expr1004] ASC, [gtpres].[GTP_Code] ASC))
                 |              |--Parallelism(Repartition Streams, PARTITION COLUMNS:([Expr1004], [gtpres].[GTP_Code]))
                 |                   |--Hash Match(Partial Aggregate, HASH:([gtpres].[GTP_Code], [Expr1004]), RESIDUAL:([gtpres].[GTP_Code]=[gtpres].[GTP_Code] AND [Expr1004]=[Expr1004]) DEFINE:([partialagg1024]=COUNT_BIG([Expr1003]), [partialagg1026]=SUM([Expr1003])))
                 |                        |--Compute Scalar(DEFINE:([Expr1004]=Convert([gtpres].[DateDST])))
                 |                             |--Compute Scalar(DEFINE:([Expr1003]=Convert([Expr1002])))
                 |                                  |--Hash Match(Aggregate, HASH:([gtpres].[GTP_Code], [gtpres].[DateDST]), RESIDUAL:([gtpres].[GTP_Code]=[gtpres].[GTP_Code] AND [gtpres].[DateDST]=[gtpres].[DateDST]) DEFINE:([Expr1002]=MAX([gtpres].[VolFact])))
                 |                                       |--Parallelism(Repartition Streams, PARTITION COLUMNS:([gtpres].[GTP_Code], [gtpres].[DateDST]))
                 |                                            |--Hash Match(Inner Join, HASH:([cal].[DateDST], [Expr1017])=([gtpres].[DateDST], [gtpres].[IntDST]), RESIDUAL:([gtpres].[DateDST]=[cal].[DateDST] AND [Expr1017]=[gtpres].[IntDST]))
                 |                                                 |--Bitmap(HASH:([cal].[DateDST], [Expr1017]), DEFINE:([Bitmap1028]))
                 |                                                 |    |--Parallelism(Repartition Streams, PARTITION COLUMNS:([cal].[DateDST]))
                 |                                                 |         |--Hash Match(Inner Join, HASH:([Expr1017])=([cal].[IntDST]), RESIDUAL:([cal].[IntDST]=[Expr1017]))
                 |                                                 |              |--Parallelism(Broadcast)
                 |                                                 |              |    |--Sort(DISTINCT ORDER BY:([Expr1017] ASC))
                 |                                                 |              |         |--Constant Scan
                 |                                                 |              |--Clustered Index Scan(OBJECT:([SQLRU].[dbo].[CALENDAR].[PK__CALENDAR__286302EC] AS [cal]), WHERE:([cal].[DayType]='РАБ'))
                 |                                                 |--Parallelism(Repartition Streams, PARTITION COLUMNS:([gtpres].[DateDST], [gtpres].[IntDST]), WHERE:(PROBE([Bitmap1028])=TRUE))
                 |                                                      |--Clustered Index Scan(OBJECT:([SQLRU].[dbo].[GTP_RESULTS].[XPKGTP_RESULTS] AS [gtpres]))
                 |--Compute Scalar(DEFINE:([Expr1012]=Convert([Expr1010])))
                      |--Compute Scalar(DEFINE:([Expr1010]=If ([globalagg1019]=0) then NULL else [globalagg1021]))
                           |--Stream Aggregate(GROUP BY:([Expr1009], [GTP_RESULTS].[GTP_Code]) DEFINE:([globalagg1019]=SUM([partialagg1018]), [globalagg1021]=SUM([partialagg1020])))
                                |--Sort(ORDER BY:([Expr1009] ASC, [GTP_RESULTS].[GTP_Code] ASC))
                                     |--Parallelism(Repartition Streams, PARTITION COLUMNS:([Expr1009], [GTP_RESULTS].[GTP_Code]))
                                          |--Hash Match(Partial Aggregate, HASH:([GTP_RESULTS].[GTP_Code], [Expr1009]), RESIDUAL:([GTP_RESULTS].[GTP_Code]=[GTP_RESULTS].[GTP_Code] AND [Expr1009]=[Expr1009]) DEFINE:([partialagg1018]=COUNT_BIG([GTP_RESULTS].[VolFact]), [partialagg1020]=SUM([GTP_RESULTS].[VolFact])))
                                               |--Compute Scalar(DEFINE:([Expr1009]=Convert([GTP_RESULTS].[DateDST])))
                                                    |--Clustered Index Scan(OBJECT:([SQLRU].[dbo].[GTP_RESULTS].[XPKGTP_RESULTS]))


WITH OPTION (MAXDOP 1)

  |--Sort(ORDER BY:([Union1013] ASC, [Union1014] ASC))
       |--Concatenation
            |--Compute Scalar(DEFINE:([Expr1005]=If ([Expr1028]=0) then NULL else ([Expr1029]/Convert([Expr1028]))))
            |    |--Hash Match(Aggregate, HASH:([gtpres].[GTP_Code], [Expr1004]), RESIDUAL:([gtpres].[GTP_Code]=[gtpres].[GTP_Code] AND [Expr1004]=[Expr1004]) DEFINE:([Expr1028]=COUNT_BIG([Expr1003]), [Expr1029]=SUM([Expr1003])))
            |         |--Compute Scalar(DEFINE:([Expr1004]=Convert([gtpres].[DateDST])))
            |              |--Compute Scalar(DEFINE:([Expr1003]=Convert([Expr1002])))
            |                   |--Hash Match(Aggregate, HASH:([gtpres].[GTP_Code], [gtpres].[DateDST]), RESIDUAL:([gtpres].[GTP_Code]=[gtpres].[GTP_Code] AND [gtpres].[DateDST]=[gtpres].[DateDST]) DEFINE:([Expr1002]=MAX([gtpres].[VolFact])))
            |                        |--Hash Match(Inner Join, HASH:([cal].[DateDST], [Expr1017])=([gtpres].[DateDST], [gtpres].[IntDST]), RESIDUAL:([gtpres].[DateDST]=[cal].[DateDST] AND [Expr1017]=[gtpres].[IntDST]))
            |                             |--Hash Match(Inner Join, HASH:([Expr1017])=([cal].[IntDST]), RESIDUAL:([cal].[IntDST]=[Expr1017]))
            |                             |    |--Sort(DISTINCT ORDER BY:([Expr1017] ASC))
            |                             |    |    |--Constant Scan
            |                             |    |--Clustered Index Scan(OBJECT:([SQLRU].[dbo].[CALENDAR].[PK__CALENDAR__286302EC] AS [cal]), WHERE:([cal].[DayType]='РАБ'))
            |                             |--Clustered Index Scan(OBJECT:([SQLRU].[dbo].[GTP_RESULTS].[XPKGTP_RESULTS] AS [gtpres]))
            |--Compute Scalar(DEFINE:([Expr1012]=Convert([Expr1010])))
                 |--Compute Scalar(DEFINE:([Expr1010]=If ([Expr1030]=0) then NULL else [Expr1031]))
                      |--Hash Match(Aggregate, HASH:([GTP_RESULTS].[GTP_Code], [Expr1009]), RESIDUAL:([GTP_RESULTS].[GTP_Code]=[GTP_RESULTS].[GTP_Code] AND [Expr1009]=[Expr1009]) DEFINE:([Expr1030]=COUNT_BIG([GTP_RESULTS].[VolFact]), [Expr1031]=SUM([GTP_RESULTS].[VolFact])))
                           |--Compute Scalar(DEFINE:([Expr1009]=Convert([GTP_RESULTS].[DateDST])))
                                |--Clustered Index Scan(OBJECT:([SQLRU].[dbo].[GTP_RESULTS].[XPKGTP_RESULTS]))

I used UNION ALL
27 ноя 09, 05:17    [7985241]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
This query works perfectly even without MAXDOP, o_o...
I just extract [DateDST] from [CALENDAR] table

SELECT CONVERT(char(7),DateDST, 120) as YYYY_MM, GTP_Code, 'Мощность по 13.2' as ResType, AVG(Power) as Power
FROM 
(
SELECT gtpres.GTP_Code, /*gtpres*/cal.DateDST, CAST(MAX(VolFact) as float) as Power
FROM CALENDAR cal
INNER JOIN GTP_Results gtpres
  ON cal.DateDST = gtpres.DateDST AND cal.IntDST = gtpres.IntDST
  AND cal.DayType = 'РАБ'
  AND cal.IntDST IN ('22-23', '21-22', '20-21', '19-20', '18-19', '17-18', '16-17', '15-16', '14-15',
                            '13-14', '12-13', '11-12', '10-11', '09-10',  '08-09', '07-08', '06-07', '05-06')
GROUP BY gtpres.GTP_Code, /*gtpres*/cal.DateDST
) t1
GROUP BY GTP_Code, CONVERT(char(7),DateDST, 120)

UNION 
SELECT CONVERT(char(7),DateDST, 120) as YYYY_MM, GTP_Code, 'Суммарная мощность' as ResType, SUM(VolFact) as Power
FROM GTP_RESULTS
GROUP BY GTP_Code, CONVERT(char(7),DateDST, 120)
ORDER BY CONVERT(char(7),DateDST, 120), GTP_Code

27 ноя 09, 05:20    [7985242]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
aleks2
Guest
На

Microsoft SQL Server 2000 - 8.00.2282 (Intel X86) Dec 30 2008 02:22:41 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

НЕ воспроизводится. Параллелизм в плане есть.
27 ноя 09, 07:33    [7985289]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Кудряшка
Member

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

Thanks! :)

Security Update for SQL Server 2000 Service Pack 4 and MSDE 2000 (KB960083) helped to fix the issue.

P.S.: Sorry for writing in english. I'm at work now.

Microsoft SQL Server 2000 - 8.00.2282 (Intel X86)
Dec 30 2008 02:22:41
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
27 ноя 09, 08:40    [7985344]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Morfeuz
Member

Откуда: Санкт-Петербург
Сообщений: 51
Хм, странно, апдейт по безопасности вроде, но после установки и у меня параллелизм заработал, как надо :)
27 ноя 09, 10:33    [7985986]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
вообще очень похоже, что гдето не хватает данных...
добавьте в добавок к AVG(Power), COUNT(*) и сравните количество. если разнится, то убирайте GROUP BY GTP_Code, CONVERT(char(7),DateDST, 120) в первом запросе и джоините таблицу через лефт джоин..

для спящего время бодрствования равносильно сну
27 ноя 09, 11:16    [7986409]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Morfeuz
Member

Откуда: Санкт-Петербург
Сообщений: 51
Алексей2003,

данные полны
27 ноя 09, 11:47    [7986697]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Алексей2003
Member

Откуда: Москва
Сообщений: 5645
в плане данные полны?

для спящего время бодрствования равносильно сну
27 ноя 09, 15:26    [7988558]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Morfeuz
Member

Откуда: Санкт-Петербург
Сообщений: 51
Алексей2003,

для каждого месяца и объекта за исключением двух периодов (2009-11 и 2009-12) количество записей в таблицах CALENDAR и GTP_RESULTS совпадает, NULL-значений тоже нет (писал выше)
27 ноя 09, 16:22    [7989034]     Ответить | Цитировать Сообщить модератору
 Re: Непонятное поведение UNION  [new]
Кудряшка
Member

Откуда: Сидней
Сообщений: 2219
Алексей2003
вообще очень похоже, что гдето не хватает данных...
добавьте в добавок к AVG(Power), COUNT(*) и сравните количество. если разнится, то убирайте GROUP BY GTP_Code, CONVERT(char(7),DateDST, 120) в первом запросе и джоините таблицу через лефт джоин..

для спящего время бодрствования равносильно сну


Вы Не правы. Посмотрите внимательно на запрос

SELECT CONVERT(char(7),DateDST, 120) as YYYY_MM, GTP_Code, 'Мощность по 13.2' as ResType, AVG(Power) as Power
FROM 
(
SELECT gtpres.GTP_Code, /*gtpres*/cal.DateDST, CAST(MAX(VolFact) as float) as Power
FROM CALENDAR cal
INNER JOIN GTP_Results gtpres
  ON cal.DateDST = gtpres.DateDST AND cal.IntDST = gtpres.IntDST
  AND cal.DayType = 'РАБ'
  AND cal.IntDST IN ('22-23', '21-22', '20-21', '19-20', '18-19', '17-18', '16-17', '15-16', '14-15',
                            '13-14', '12-13', '11-12', '10-11', '09-10',  '08-09', '07-08', '06-07', '05-06')
GROUP BY gtpres.GTP_Code, /*gtpres*/cal.DateDST
) t1
GROUP BY GTP_Code, CONVERT(char(7),DateDST, 120)

UNION 
SELECT CONVERT(char(7),DateDST, 120) as YYYY_MM, GTP_Code, 'Суммарная мощность' as ResType, SUM(VolFact) as Power
FROM GTP_RESULTS
GROUP BY GTP_Code, CONVERT(char(7),DateDST, 120)
ORDER BY CONVERT(char(7),DateDST, 120), GTP_Code

1.если выбирать DateDST из таблицы CALENDAR - все хорошо
если из таблицы GTP_Results - суммарные данные для первого запроса все занижены

2. В оригинальном запросе автора, где DateDST выбирается из GTP_Results проблема лечится указанием опции MAXDOP

3. Проблема просто лечится установкой security update

Причем тут данные???
28 ноя 09, 01:30    [7990929]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить