Sayısal yayın yaparken garip SQL Server örneği çökmesi


20

C # Entity Framework ile çalışırken SQL Server örneğimin çöktüğünü fark ettim.

Bu ifadeye kadar takip edebildim:

SELECT * FROM dbo.[TestTable]
where mpnr in (1099059904,
1038139906,
1048119902,
1045119902,
1002109903,
1117109910,
1111149902,
1063149902,
1117159902,
1116109904,
1105079905,
1012079906,
1129129904,
1103059905,
1065059905,
1091059906,
1110149904,
1129149903,
1083029905,
1080139904,
1076109903,
1010019902,
1058019902,
1060019903,
1053019902,
1030089902,
1018149902,
1077149902,
1010109901,
1011109901,
1000119902,
1023049903,
1107119909,
1108119909,
1106119909)

Tablo şöyle:

CREATE TABLE dbo.[TestTable]([MPNR] [numeric](9, 0) NOT NULL)

Sorgu her başlatıldığında kilitlenme oluşur. INMadde içindeki değerlerin sayısını azaltırsam çalışır. (Tabii ki hiç satır döndürmez.)

Ben değerleri farkındayım INfıkra 10 basamaklı sayılardır ve sütun sadece 9-basamak vardır, ama bu bütün SQL Server örneği bir çökmesine neden olmamalıdır.

SQL Server'ımın sürümü, Windows Server 2003 32 bit üzerinde 2008 R2'dir.

Bu bilinen bir hata mı? SQL Server için bir Yama var mı?


Yorumlar uzun tartışmalar için değildir; bu sohbet sohbete taşındı .
Paul White, GoFundMonica diyor ki

Yanıtlar:


20

2008 R1 SP3 10.00.5512'de repro yapabildim, ancak en son CU'yu (14) yüklemek sorunu çözdü.

Araya giren sürümlerde düzeltilen hataları incelemek, aşağıdaki düzeltmeyi içeren bir yapıya yükseltmeniz gerektiği gibi görünüyor.

SQL Server 2008 veya SQL Server 2012'de bir IN yan tümcesinde çok sayıda sabit değer içeren bir sorgu çalıştırdığınızda erişim ihlali

2008 R2'de olduğunuz için SP1 için en az 9 PB veya SP2 için 5 PB gerekir.

Semptomların tanımı biraz kısadır, ancak eşleşmeyen veri türlerinden bahseder

Microsoft SQL Server 2008, Microsoft SQL Server 2012 veya Microsoft SQL Server 2008 R2'de bir IN yan tümcesinde çok sayıda sabit değer içeren bir sorgu çalıştırdığınızda erişim ihlali oluşabilir.

Not Sorunun oluşması için, IN yan tümcesindeki sabitler sütun veri türüyle tam olarak eşleşemez.

"Çok" tanımlamaz. Testten, bunun "20 veya daha fazla" anlamına gelebileceğinden şüpheleniyordum, çünkü bu, kardinaliteyi tahmin etmenin iki farklı yöntemi arasındaki kesme noktası gibi görünüyor.

Kaza, ve CScaOp_In::FCalcSelectivity()gibi isimlerle adlandırılan birkaç yöntem içinde gerçekleşiyordu .LoadHistogramFromXVariantArray()CInMemHistogram::FJoin() -> WalkHistograms()

Liste öğelerinde 19 veya daha az farklı olan için bu yöntemler hiç çağrılmadı. Bir benzer bir SQL Sever 2000 hata da anlamlı olarak kapatma noktasına bu kesim bahseder.

0 ile 1047 arasında değerler ve aşağıdaki gibi başlayan bir histogram içeren 100.000 sıra rastgele test verisi içeren bir test tablosu doldurma

+--------------+------------+---------+---------------------+----------------+
| RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS | DISTINCT_RANGE_ROWS | AVG_RANGE_ROWS |
+--------------+------------+---------+---------------------+----------------+
|            0 |          0 |     104 |                   0 | 1              |
|            8 |        672 |     118 |                   7 | 96             |
|           13 |        350 |     118 |                   4 | 87.5           |
|           18 |        395 |     107 |                   4 | 98.75          |
|           23 |        384 |      86 |                   4 | 96             |
|           28 |        371 |      85 |                   4 | 92.75          |
+--------------+------------+---------+---------------------+----------------+

Sorgu

SELECT * FROM dbo.[TestTable]
where mpnr in (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19)
option (maxdop 1)

Tahmini 1856 satırlarını gösterir.

19 eşitlik için tahmini satırların tek tek tahmin edilmesi ve bir araya getirilmesiyle tam olarak beklenen budur.

+-------+----------------+-------+
| 1-7   | AVG_RANGE_ROWS | 96    |
| 8     | EQ_ROWS        | 118   |
| 9-12  | AVG_RANGE_ROWS | 87.5  |
| 13    | EQ_ROWS        | 118   |
| 14-17 | AVG_RANGE_ROWS | 98.75 |
| 18    | EQ_ROWS        | 107   |
| 19    | AVG_RANGE_ROWS | 96    |
+-------+----------------+-------+

7*96 + 118 + 4*87.5 + 118 + 4*98.75 + 107 + 1*96 = 1856

Formül artık çalışmaya başlamıyor sonra 20listeye eklenir (Toplama başka bir etiket eklemek 1902.75yerine tahmin edilen satırlar ).195296

BETWEEN kardinalite tahminlerini hesaplamak için başka bir yöntem kullanıyor gibi görünüyor.

where mpnr BETWEEN 1 AND 20yalnızca 1829.6 satırı tahmin eder. Bunun gösterilen histogramdan nasıl türetildiği hakkında hiçbir fikrim yok.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.