Рушится вера в / Microsoft SQL Server

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Рушится вера в

35 сообщений из 35, показаны все 2 страниц

все

Рушится вера в

#32047182

qu-qu

Участник

Сообщения: 9 135

Рейтинг: 0 / 0

Делаю тестовую процедурку...
Цель: заполнить значениями в произвольном порядке одну таблицу, и перегрузить из нее данные в другую, но уже с определенным порядком сортировки.

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.

create proc #test_proc
as
set nocount on
declare @curr_date datetime select @curr_date = getdate()
create table #t1 (f0 datetime, f1 int)
insert into #t1
select dateadd(dd,-  1 , @curr_date),  3 
insert into #t1
select dateadd(dd,-  2 , @curr_date),  2 
insert into #t1
select dateadd(dd,-  3 , @curr_date),  4 
insert into #t1
select dateadd(dd,-  4 , @curr_date),  4 
insert into #t1
select dateadd(dd,-  1 , @curr_date),  1 

select * from #t1
select * into #t2 from #t1
select * from #t2
truncate table #t2
insert into #t2 select * from #t1 order by f1,f0
select * from #t2
truncate table #t2
insert into #t2 select * from #t1 order by f0,f1
select * from #t2
go

select @@version

exec #test_proc

Получаю результат (ожидаемый):

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.

 ------------------------------------------------------------------------------------------------------------------------- 
 
Microsoft SQL Server   6 . 50  -  6 . 50 . 479  (Intel X86) 
	Jun  14   2000   16 : 12 : 29  
	Copyright (c)  1988 - 1997  Microsoft Corporation


f0                          f1          
 --------------------------- ----------- 
 
 2002 - 08 - 29   15 : 02 : 45 . 743       3 
 2002 - 08 - 28   15 : 02 : 45 . 743       2 
 2002 - 08 - 27   15 : 02 : 45 . 743       4 
 2002 - 08 - 26   15 : 02 : 45 . 743       4 
 2002 - 08 - 29   15 : 02 : 45 . 743       1 

f0                          f1          
 --------------------------- ----------- 
 
 2002 - 08 - 29   15 : 02 : 45 . 743       3 
 2002 - 08 - 28   15 : 02 : 45 . 743       2 
 2002 - 08 - 27   15 : 02 : 45 . 743       4 
 2002 - 08 - 26   15 : 02 : 45 . 743       4 
 2002 - 08 - 29   15 : 02 : 45 . 743       1 

f0                          f1          
 --------------------------- ----------- 
 
 2002 - 08 - 29   15 : 02 : 45 . 743       1 
 2002 - 08 - 28   15 : 02 : 45 . 743       2 
 2002 - 08 - 29   15 : 02 : 45 . 743       3 
 2002 - 08 - 26   15 : 02 : 45 . 743       4 
 2002 - 08 - 27   15 : 02 : 45 . 743       4 

f0                          f1          
 --------------------------- ----------- 
 
 2002 - 08 - 26   15 : 02 : 45 . 743       4 
 2002 - 08 - 27   15 : 02 : 45 . 743       4 
 2002 - 08 - 28   15 : 02 : 45 . 743       2 
 2002 - 08 - 29   15 : 02 : 45 . 743       1 
 2002 - 08 - 29   15 : 02 : 45 . 743       3

Вера начинает рушиться когда ТЕ ЖЕ САМЫЕ конструкции в реальной "боевой" процедуре, которая работает с реальными данными приложения - возвращают данные с абсолютно "абстрактным" порядком сортировки (не имеющим отношения ни к дате, ни к номеру).

Что бы это значило?
Может кто-нибудь уже сталкивался с такими "глюками" в конструкциях типа:

Код: plaintext

 select * into #table2 from #table1 order by ....

...

Рейтинг:

0 / 0

30.08.2002, 15:10:23

| Ответить | Цитировать | Написать

Рушится вера в

#32047190

MarchCat

Участник

Откуда: Из Сибири.

Сообщения: 1 439

Рейтинг: 0 / 0

Скорее всего, стоит order by 2, 4
А в реальном селекте имена - name, spis_dat
Проверь соответствие.

...

Рейтинг:

0 / 0

30.08.2002, 15:24:06

| Ответить | Цитировать | Написать

Рушится вера в

#32047191

Tulkin

Участник

Откуда: Киев

Сообщения: 267

Рейтинг: 0 / 0

Я думаю, что SQL совсем не обязан в селекте сортировать данные,если ему этого не сказали. Ну было у него пол-таблицы в кэше. он мог сначалы их и выдать, а потов вторую половину - с диска.(утрированно)

...

Рейтинг:

0 / 0

30.08.2002, 15:27:54

| Ответить | Цитировать | Написать

Рушится вера в

#32047196

Автор

Гость

В таблице есть индексы ?

...

Рейтинг:

0 / 0

30.08.2002, 15:36:09

| Ответить | Цитировать | Написать

Рушится вера в

#32047204

ziktuw

Участник

Сообщения: 3 335

Рейтинг: 0 / 0

"Рушится вера в " ... в собственное представление, как должен работать MSSQL. И вобщем, правильно. Он работает не так, и не должен.
Единственный документированый способ получить отсортированый набор данных - это ORDER BY в селекте. Остальное - от лукавого.

...

Рейтинг:

0 / 0

30.08.2002, 15:48:07

| Ответить | Цитировать | Написать

Рушится вера в

#32047251

qu-qu

Участник

Сообщения: 9 135

Рейтинг: 0 / 0

2 MarchCat
... Скорее всего, стоит order by 2, 4
А в реальном селекте имена - name, spis_dat...

Откуда такая уверенность в том - что у меня стоит в "реальном селекте"?
Ты что - ясновидец?
Я же ясно написал - точно такая же конструкция (естественно - имена таблиц и полей - другие, но это именно не номера столбцов, а их имена).

2 Tulkin
... Я думаю, что SQL совсем не обязан в селекте сортировать данные,если ему этого не сказали...

Как ты считаешь - "insert into #t2 select * from #t1 order by f0, f1" - это "не сказали", или "сказали" сортировать?

... Ну было у него пол-таблицы в кэше. он мог сначалы их и выдать, а потов вторую половину - с диска.(утрированно)...

Скажу по-секрету только тебе - в рабочей выборке всего-навсего 84 записи во временной таблице. Как ты считаешь - сколько из них выбирается из кэша, а сколько "с диска"?

2 Member
... В таблице есть индексы ?...

Изначально - не было. Когда я наткнулся на этот "затык" - сделал парочку временных индексов (на поля сортировки в исходной таблице и в целевой). Эффект - нулевой, что с индексами, что без - поведение одинаково "безобразное".

2 Dankov
... Единственный документированый способ получить отсортированый набор данных - это ORDER BY в селекте...

См. выше (ответ 2 Tulkin ) - если я пишу ORDER BY в селекте, который стоит после инсерта - это что - повод его не выполнять? Или - выполнять избирательно?
(если ты внимательно вглядишься в текст и результаты приведенного выше примера - увидишь, что там директива ORDER BY исполняется очень даже правильно (и по первому полю, и по второму), какой же тогда смысл - не исполнять ее в других процедурах на других таблицах?)

...

Рейтинг:

0 / 0

30.08.2002, 18:11:43

| Ответить | Цитировать | Написать

Рушится вера в

#32047252

GreenSunrise

Участник

Сообщения: 12 400

Рейтинг: 0 / 0

qu-qu, тот order by, который стоит в селекте select * from #t1, выполняется. Но в select * from #t2 ты же order by не ставишь. Да плевать на то, что в таблицу ты вставил ОТСОРТИРОВАННЫЕ записи. Выборку из нее ты делаешь БЕЗ СОРТИРОВКИ. Что тебе и пытаются объяснить.

...

Рейтинг:

0 / 0

30.08.2002, 18:27:58

| Ответить | Цитировать | Написать

Рушится вера в

#32047265

SergCat

Гость

У меня была похожая ситуация. Только данные в таблицу вставлялись на основе сложной выборки с вложенными селектами.
И, теоретически, данные должны были вставлятся во временную таблицу в порядке, определенном order by. На самом же деле этого не происходило.
На этом форуме уже звучала следующая мысль, которая на практике работает в 2000-м sql:
1. Для определения точного следования записей во временной таблице надо использовать primary key
2. В переменной типа "таблица" записи следуют в порядке их добавления.
(на самом деле никто не несет ответственности, что это будет работать в Yukon и т.д.)
Советы:
1. Создать для #t2 primary key
2. Вместо #t2 использовать @t2.

...

Рейтинг:

0 / 0

30.08.2002, 20:55:11

| Ответить | Цитировать | Написать

Рушится вера в

#32047271

MiCe

Участник

Откуда: RUSSIA STAVROPOL Pyatigorsk

Сообщения: 2 002

Рейтинг: 0 / 0

доблю что кластерный индекс....

...

Рейтинг:

0 / 0

30.08.2002, 21:55:30

| Ответить | Цитировать | Написать

Рушится вера в

#32047303

SergCat

Гость

Вероятно "доблю" означает "добавлю" :-)
Совершенно верно. Суть не в primary key, а в создании кластерного индекса.

...

Рейтинг:

0 / 0

31.08.2002, 16:49:32

| Ответить | Цитировать | Написать

Рушится вера в

#32047306

MiCe

Участник

Откуда: RUSSIA STAVROPOL Pyatigorsk

Сообщения: 2 002

Рейтинг: 0 / 0

угу... очяпятылси......

...

Рейтинг:

0 / 0

31.08.2002, 17:32:49

| Ответить | Цитировать | Написать

Рушится вера в

#32047307

Tulkin

Участник

Откуда: Киев

Сообщения: 267

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

31.08.2002, 17:34:41

| Ответить | Цитировать | Написать

Рушится вера в

#32047309

MiCe

Участник

Откуда: RUSSIA STAVROPOL Pyatigorsk

Сообщения: 2 002

Рейтинг: 0 / 0

а вот физичекое размещение ни кто не гарантирует....
логическое это да .... физически экстэнты могут быть фрагментированы....

...

Рейтинг:

0 / 0

31.08.2002, 17:39:06

| Ответить | Цитировать | Написать

Рушится вера в

#32047312

Tulkin

Участник

Откуда: Киев

Сообщения: 267

Рейтинг: 0 / 0

ну блин че к словам цепляться. понял ведь че я имел ввиду :-)

...

Рейтинг:

0 / 0

31.08.2002, 18:38:52

| Ответить | Цитировать | Написать

Рушится вера в

#32047315

MiCe

Участник

Откуда: RUSSIA STAVROPOL Pyatigorsk

Сообщения: 2 002

Рейтинг: 0 / 0

сори.... если что.....
просто уточнил - для правильного понимания.....

...

Рейтинг:

0 / 0

31.08.2002, 22:38:08

| Ответить | Цитировать | Написать

Рушится вера в

#32047321

qu-qu(дома)

Гость

Для начала - цитата:
" - Очень сожалею, но Ваш друг умер. У него 2 часа ночи произошло кровоизлияние в мозг.
- Че... че ты гонишь?! Какое "кровоизлияние"?! В КАКОЙ МОЗГ??!! " (© "Агент национальной безопасности")

Вот во что у меня точно скоро вся вера порушится, так это в то, что в этом форуме "выступают" нормальные разумные люди...

Словей-то умных все понавыучивали: "оптимизатор", "экстенты", "производительность", "физическое размещение"...
А кто-нибудь из "советчиков" обратил внимание на результат запроса select @@version
из моего примера? А мне приходится работать именно с такой версией, без всяких "экстентов", и с совершенно другим "оптимизатором", и "физическое размещение" в нем - тоже совсем другое.

Единственный человек высказался "по делу" ( SergCat , спасибо) т.к. сталкивался с подобной проблемой именно в деле, да и то - primary key с clustered index попутал... Ну это как раз ничего - все ошибаются, если это нормальные люди.

А вот остальные - что делали в этом топике? Доказывали непонятно кому и непонятно зачем - собственное превосходство в понимании синтаксиса T-SQL? И до чего же в итоге "договорились"?
Оказывается - поскольку "физическое размещение" записей никем и ничем не гарантируется (даже в "Юконе", о-о-о-о, Великий "Юкон", прости меня грешного, что вспомнил Твое Имя всуе...), то select без order by - будет возвращать записи в каком угодно порядке, от раза к разу все более причудливом (наверное специально, чтобы скучно не было - "получать 25 000 одинаковых наборов на 25 000 одинаковых запросов - что за фигня такая?").

Вам самим-то с себя - не смешно?
Или кто-нибудь хоть 1 из вас всех когда-нибудь хоть 1 раз в жизни слышал о том (не приведи "Юкон" - видел своими глазами), что запрос select без order by - возвращал записи в разном порядке от запуска к запуску?

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

А если кто-то еще сомневается в том, что select без order by к временной таблице из 100 строчек возвращает записи в порядке их "физического размещения" - готовьтесь просматривать тут логи выполнения DBCC TRACEON (только флаги подходящие найду в и-нете, т.к. являюсь нормальным человеком и не в состоянии все на свете знать и помнить наизусть).

...

Рейтинг:

0 / 0

01.09.2002, 00:08:26

| Ответить | Цитировать | Написать

Рушится вера в

#32047332

locky

Участник

Откуда: Харьков, Украина

Сообщения: 66 149

Рейтинг: 0 / 0

>Или кто-нибудь хоть 1 из вас всех когда-нибудь хоть 1
>раз в жизни слышал о том (не приведи "Юкон" - видел
>своими глазами), что запрос select без order by -
>возвращал записи в разном порядке от запуска к запуску?

Видел. И неонократно.
Никто не гарантирует порядок выборки если не указано условие сортировки.

Пример навскидку:
SomeTable - таблица с кластерным индексом

select * from SomeTable
go
select * from SomeTable
go

Предположим, что сервер свежезапущенный, кэш данных пустой.

при первой выборке выбираются данные из таблицы в порядке кластерного индекса, ПРЕДПОЛОЖИТЕЛЬНО, с 1-й страницы. По ходу дела часть данных кэшируется.
При второй выборке последняя страница уже лежит в кэше, она и будет (СКОРЕЕ ВСЕГО) выдана первой, т.к. не указано условие сортировки.
SQL SERVER предпочитает не делать лишней работы.
При более сложных выборках результат может быть еще непредсказуемее, т.к. порядок выдачи результат будет зависит от того, сколько каких данных из каких таблиц скеэшировано, от порядка соединения, индексов и т.д.
А собственно, сортировать данные, когда этого не просят, никто и не обещал. уж больно накладная и никому не нужная(в данном случае) операция.

...

Рейтинг:

0 / 0

01.09.2002, 15:00:04

| Ответить | Цитировать | Написать

Рушится вера в

#32047342

qu-qu(дома)

Гость

"Ну вы, блин, даете..." (© Генерал Иволгин)

Еще одному апологету Всепоглощающего Кэша и Всепроникающего Оптимизатора - неймется высказаться:

Пример навскидку:
SomeTable - таблица с кластерным индексом

select * from SomeTable
go
select * from SomeTable
go

Предположим, что сервер свежезапущенный, кэш данных пустой.

Вот беру я у себя дома сервер свежезапущенный , пишу ему в базу pubs:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.

set nocount on
create table SomeTable (i int not null, c varchar( 8000 ) null)
create clustered index SomeIndex on SomeTable (i)
declare @counter int
set  @counter =  25000 
while @counter >  0 
begin 
	insert into SomeTable (i,c) select @counter, ''
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
	set @counter = @counter -  1 
	if (select @counter %  1000 ) =  0  print @counter
end

Через 40 сек. - у меня таблица с 25 000 записей, где каждая запись ровно на пол-страницы данных, или можно считать по другому - на каждой странице данных по 2 записи из таблицы.

Перегружаюсь... (полностью с операционкой, чтобы быть уверенным, что кэш данных пустой ).
Спрашиваю у него:

Код: plaintext

1.
2.
3.

 select * from SomeTable
go
 select * from SomeTable
go

3 раза спрашиваю... каждый "спрос" - целых 3.5 мин. обрабатывается... ну ничего - я терпеливый... (чаек пью в перерывах, курю, телик смотрю). Результат - ожидаемый: все записи в обоих наборах данных - выводятся строго в порядке кластерного индекса.

Ладно, надоедает мне "спрашивать" просто так... открываю другое окошко в QA - и начинаю в другом окошке спрашивать другое, а именно:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.

set nocount on
declare @counter int, @i int, @c varchar( 8000 )
set  @counter =  100000 
while @counter >  0 
begin 
	select @i = max(i), @c = min(c) from SomeTable where i between  11000  and  11010 
	set @counter = @counter -  1 
	if (select @counter %  5000 ) =  0  print @counter
end

Смотрю как цифирки бегут в окошке вывода (текстовый режим выбрал специально), радуюсь, что уж тут-то мой умненький сервачок закеширует эти несчастные 5 страниц данных, которые его заставляют 100 000 раз находить и 100 000 раз анализировать на минимум текстового поля и максимум числового...

А в другом окошке - предыдущие 2 селекта "сандалят" вовсю... данные гонят... Но что-то помедленнее они стали их выдавать "на гора" после того, как я параллельно 100 000 раз совсем про другое начал сервачок спрашивать...
Ну ничего, я терпеливый... Пока окончания нужных мне селектов не видно - я снова и снова запускаю 100 000-ный вопрос... (скажу честно - пока дождался 12 раз успел запустить, а записи из 2-х селектов как выводились в порядке кластерного индекса - так и выводятся).

Что же это получается? Сервер честно в одном процессе МИЛЛИОН(!!) раз опрашивал одни и те же 5 страниц данных, а в другом процессе - НИ РАЗУ не выдал эти 5 страниц раньше, чем 5 500 страниц из начала таблицы, про которые ему давно следовало бы "забыть" нахрен, т.к. после них он еще считывал 7 495 страниц из конца таблицы.

Что-то здесь не так, не то с "кешированием", не то с "оптимизацией", и что самое интересное - никаких ПРЕДПОЛОЖИТЕЛЬНО и СКОРЕЕ ВСЕГО не наблюдается...
Все предельно ясно и определенно.

Так что с примерчиками - поосторожнее в следующий раз... (их ведь, и проверить можно).

...

Рейтинг:

0 / 0

01.09.2002, 19:42:22

| Ответить | Цитировать | Написать

Рушится вера в

#32047347

Alexandr Kizchenko

Гость

Добрый день!
2qu-qu

Кажется вы забыли в чем суть SQL. Почитайте Грабера. Это же не Паскаль и не Си. С помощью SQL вы говорите КАКИЕ ДАННЫЕ ВАМ НУЖНЫ, а не ЧТО ДЕЛАТЬ СЕРВЕРУ. Поэтому: если в запросе не указан ORDER BY в SELECT , то сервер не гарантирует строгий порядок записей.
Советую пересмотреть алгоритм процедуры, например вместо
insert into #t2 select * from #t1 order by f1,f0
select * from #t2
написать
insert into #t2 select * from #t1
select * from #t2 order by f1,f0

...

Рейтинг:

0 / 0

02.09.2002, 05:08:41

| Ответить | Цитировать | Написать

Рушится вера в

#32047348

Alexandr Kizchenko

Гость

2 qu-qu
и еще в догонку
Конструкция
insert into #t2 select * from #t1 order by f0,f1
select * from #t2

не равна кострукции
select * into #table2 from #table1 order by ....

...

Рейтинг:

0 / 0

02.09.2002, 05:19:34

| Ответить | Цитировать | Написать

Рушится вера в

#32047362

SergSuper

Участник

Откуда: SPb

Сообщения: 5 995

Рейтинг: 0 / 0

2 qu-qu
А Вы допускаете, что можете ошибаться?

...

Рейтинг:

0 / 0

02.09.2002, 10:04:06

| Ответить | Цитировать | Написать

Рушится вера в

#32047366

alexeyvg

Участник

Откуда: Moscow

Сообщения: 26 926

Рейтинг: 0 / 0

2qu-qu

Кстати, о МИЛЛИОНЕ тестов.

Ф-я NEWID ( ) на одной машине возвращала случайные числа. Это использовалось для случайной сортировки и долго и хорошо работало. А потом перенесли приложение на другой сервер - и чила стали последовательные, как идентити...

Так что МИЛЛИОН тестов - не аргумент. Ссылайтесь, пожалуйста, на документацию. Если не работает - пишите в МС, Вам пришлют фикс.

...

Рейтинг:

0 / 0

02.09.2002, 10:49:59

| Ответить | Цитировать | Написать

Рушится вера в

#32047381

ziktuw

Участник

Сообщения: 3 335

Рейтинг: 0 / 0

qu-qu, вы исходите в своих рассуждениях из 2-х ошибочных предпосылок:
1) Вы считаете, что после запроса "insert ...select..order" данные расположаться именно в том порядке, в каком определено в этом запросе. На самом деле это не так. Выборка-кэш, подготавливаемая для вставки, действительно будет отсортирована, но при размещении записей из выборки, sql-сервер будет руководствоваться не порядком записей в этой выборке, а своими внутренними определенными механизмами. На разные страницах записи вполне могут сливаться несколькими потоками из этой выборки (нарушение сортировки раз), упорядочиваясь внутри страницы по кластерному индексу (нарушение сортировки два), фиксация списка страниц с учетом дерева кластерного индекса (нарушение сортировки три). Сами страницы не обязаны располагаться последовательно в файле. Таким образом, уже после вставки хранящиеся данные уже не отсортированы в вашем понимании.
2) Вы считаете, что при указании select без order, данные будут считаны в выборку в порядке физического хранения. Это тоже неверная предпосылка. Позвольте уж серверу в силу соображений performance считать страницы несколькими потоками в том порядке, в каком ему покажется удобнее, склеить выборку из этих считываний первым попавшимся образом и опустить процесс ее сортировки, ибо, как посчитает сервер, раз не задано order by, значит какого бы то ни было порядка и требуется.

qu-qu, по-моему вы придираетесь к sql-серверу необосновано. Вам дано средство сортировки - order by в выражении select, чего же еще не хватает? Вы же не требуете от автопроизводителей, чтобы машина могла ездить без колес. Если рассуждать вашей логикой, то и здесь можно докопаться.

...

Рейтинг:

0 / 0

02.09.2002, 12:01:37

| Ответить | Цитировать | Написать

Рушится вера в

#32047401

qu-qu

Участник

Сообщения: 9 135

Рейтинг: 0 / 0

2 Alexandr Kizchenko
на: ...Кажется вы забыли в чем суть SQL. Почитайте Грабера...

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

2 SergSuper
на: А Вы допускаете, что можете ошибаться?

Очень даже - допускаю... Но все что мне до сих пор приходилось читать в этом топике - это голословные утверждения, основанные на точно такой же "слепой вере" в собственное понимание "сути SQL", почерпнутое даже не из опыта работы с ним (SQL-ем), а из книг...
Ну верят люди в то, что сервер может возвращать результаты одного и того же селекта - в различной последовательности... Что же я с ними могу поделать? Примеры мои - им не доказательство... Своих примеров - они не приводят (или приводят - "липовые", такие же умозрительные как и их вера).
Вот когда мне приведут здесь код на T-SQL, который действительно возвращает хотя бы 2 различных набора на 2 одинаковых простых селекта (без условий и сортировки) - тогда я признаю себя неправым...
А до этого - увольте.

2 alexeyvg
на: Ф-я NEWID ( ) на одной машине возвращала случайные числа.... перенесли приложение на другой сервер - и чила стали последовательные, как идентити...

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

...

Рейтинг:

0 / 0

02.09.2002, 12:52:44

| Ответить | Цитировать | Написать

Рушится вера в

#32047411

Tulkin

Участник

Откуда: Киев

Сообщения: 267

Рейтинг: 0 / 0

2 qu-qu
Слышь,чувак! прикол в том, что и "экстенты", "оптимизатор", и "физическое размещение" были еще в Sybase SQL Server 4.X, после которого пути Sybase и MS разошлись. И мне приходится делать над собой усилие, чтобы не ответить тебе грубостью на грубость(уже вторую).И прежде,чем выносить вердикт, что в этом форуме все "не нормальные", и им в этом топике не место, подумай о своей "нормальности". А что смешно, так это то, что тебе неделю талдычат истину, а ты не догоняешь, или делаешь вид что не догоняешь.

...

Рейтинг:

0 / 0

02.09.2002, 13:11:49

| Ответить | Цитировать | Написать

Рушится вера в

#32047424

qu-qu

Участник

Сообщения: 9 135

Рейтинг: 0 / 0

2 Dankov
на: Вы считаете, что после запроса "insert ...select..order" данные расположаться именно в том порядке, в каком определено в этом запросе. На самом деле это не так.

Я и сам вижу в своей рабочей процедуре, что это "не так" - потому и самый первый вопрос адресовал тем, кто уже сталкивался с подобными проявлениями работы сервера... (а вовсе не - "теоретикам от SQL").
Ну не доводилось мне до сих пор наблюдать такого "поведения" - что в этом плохого? Или это повод - считать меня тупым?

на: Вы считаете, что при указании select без order, данные будут считаны в выборку в порядке физического хранения. Это тоже неверная предпосылка.

Это я так уж - в пылу полемики "упростил до невозможности", и конечно же - был неправ... (на самом деле - помню я все топики на этом форуме, где обсуждались подобные вещи, и где всеобщим согласием договорились, что типа: "... верить можно только - кластерному индексу, да и то - с оглядкой...").

на: ... Позвольте уж серверу в силу соображений performance считать страницы несколькими потоками...

Вот здесь уже можно - поспорить с вами, т.к. внутреннего кода MS-SQL-сервера не видели - ни вы, ни я... А читать что-либо "несколькими потоками" - это тоже тратить performance на переключение и синхронизацию между этими потоками, да плюс еще - на "сборку" результата... неувязочка тут - проще будет - в одном потоке, "в лоб", перебором, скажем, кластерного индекса (за неимением лучшего критерия).

на: ... по-моему вы придираетесь к sql-серверу необосновано...

Вот уж чего не хотел, начиная эту "бодягу", так это - "придираться" к инструменту, который меня "кормит", почитай, уже 8 лет... :-)).
Понять хочу - это правда... (к сожалению - не всегда удается, даже с помощью этого замечательного ресурса).

...

Рейтинг:

0 / 0

02.09.2002, 13:33:36

| Ответить | Цитировать | Написать

Рушится вера в

#32047427

Сат

Участник

Откуда: Kiev

Сообщения: 60

Рейтинг: 0 / 0

2 Tulkin
а истина то в чем? в том что все ВИДЕЛИ и ЧИТАЛИ миллионы раз про суть SQL, но конкретный пример не могут привести?

...

Рейтинг:

0 / 0

02.09.2002, 13:35:32

| Ответить | Цитировать | Написать

Рушится вера в

#32047434

qu-qu

Участник

Сообщения: 9 135

Рейтинг: 0 / 0

2 Tulkin

Слышь, чувак!
Лихо у тебя недели мелькают (с 30-го августа по 2-е сентября - уже одна пролетела).
Давай не будем скатываться на грубости, беру свои слова про "не нормальных" - обратно, в отношении всех присутствующих...

Тебе же лично предлагаю на спор ("на слабо") - за ящик пива - через неделю представить здесь в этом топике код на T-SQL, который после дописывания в него 4-х строчек:

Код: plaintext

1.
2.
3.
4.

select * from SomeTable 
go 
select * from SomeTable 
go

... вернет 2 набора данных с различными порядками сортировки.

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

...

Рейтинг:

0 / 0

02.09.2002, 13:49:18

| Ответить | Цитировать | Написать

Рушится вера в

#32047437

Владимир Смирнов

Участник

Откуда: Северодвинск

Сообщения: 258

Рейтинг: 0 / 0

Чтобы проверить порядок вставки записей в таблицу #t1 можно добавить в структуру таблицы поле identity, а при выборке посмотреть по этому полю, в каком-же порядке на самом деле вставлялись записи.

...

Рейтинг:

0 / 0

02.09.2002, 13:57:24

| Ответить | Цитировать | Написать

Рушится вера в

#32047443

Alexandr Kizchenko

Гость

2 qu-qu
на:
наверное думаете, что я - ничего про это вообще ни разу не слышал

создается такое впечатление...

хотелось бы узнать почему вы решили что команда insert into #t2 select * from #t1 order by f1,f0 будет физически располагать на диске записи в той последовательности, в какой они выбираются из t1 ? К этому его никто не обязывает.

...

Рейтинг:

0 / 0

02.09.2002, 14:15:47

| Ответить | Цитировать | Написать

Рушится вера в

#32047454

qu-qu

Участник

Сообщения: 9 135

Рейтинг: 0 / 0

2 Alexandr Kizchenko
на: хотелось бы узнать почему вы решили что команда insert into #t2 select * from #t1 order by f1,f0 будет физически располагать на диске записи в той последовательности, в какой они выбираются из t1 ?

Так в самом же первом посте - пример приведен (лень код читать, что ли?).

Там даже 3 раза специально сделан insert - без сортировки, и с сортировкой по различным полям... и результаты 4-х селектов - приведены... (исходная таблица + 3 целевых).
У вас что - другие результаты получаются? (так приводите их сюда - пиво "срубите" на халяву).
Или вы - в книжках читаете - что "должно" получиться? (так в книжках - пиво и пейте).

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

...

Рейтинг:

0 / 0

02.09.2002, 14:34:21

| Ответить | Цитировать | Написать

Рушится вера в

#32047475

Tulkin

Участник

Откуда: Киев

Сообщения: 267

Рейтинг: 0 / 0

2 qu-qu
Пиво это конечно хорошо, но задачу ты видоизменил.
Сложно представить себе случай, когда

Код: plaintext

1.
2.
3.
4.
5.

[/src]
select * from SomeTable 
go 
select * from SomeTable 
go
[src]

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

...

Рейтинг:

0 / 0

02.09.2002, 15:03:03

| Ответить | Цитировать | Написать

Рушится вера в

#32047500

AlexP

Участник

Откуда: СПб

Сообщения: 621

Рейтинг: 0 / 0

to qu-qu

Цитата из BOL:

ORDER BY is important because relational theory specifies that the rows in a result set cannot be assumed to have any sequence unless ORDER BY is specified. ORDER BY must be used in any SELECT statement for which the order of the result set rows is important.

Видать, и в MS теоретики пролезли.

Черным по белому: если поставить ORDER BY, порядок гарантирован. Если не поставить ORDER BY, порядок не гарантирован. Какие тут могуть быть вопросы? 1000000 раз проверил, было одинаково, так и всегда будет одинаково? Да в MS кто-нибудь чихнет, и ты после очередного SP получишь другой порядок. У тебя работает, но этого никто не обещал. Ну, вольному - воля.

...

Рейтинг:

0 / 0

02.09.2002, 15:43:42

| Ответить | Цитировать | Написать

Рушится вера в

#32047508

qu-qu

Участник

Сообщения: 9 135

Рейтинг: 0 / 0

Юконе, ты, Боже ж мой!!!

Меня уже цитатками из BOL - глушить начали... :-)).
Не, пора закрывать этот топик нафик - от пива уже отказались... за дурака меня - по-прежнему считают... (хотя, просил же как человеков - "не считайте меня за дурака").

Спасибо всем - за внимание... до встречи - в эфире (в других топиках).

...

Рейтинг:

0 / 0

02.09.2002, 15:59:50

| Ответить | Цитировать | Написать

Рушится вера в

#32047584

locky

Участник

Откуда: Харьков, Украина

Сообщения: 66 149

Рейтинг: 0 / 0

Попробуйте так

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.

set nocount on
create table #t1 (id int)
create table #t2 (id int)
declare	@id int
select	@id =  1 
while @id <  10  begin
	insert into #t1(id) values(@id)
	if @id /  2  *  2  = @id insert into #t2(id) values(@id)
	select	@id = @id +  1 
end

 /*вариант 1*/ 
select  top  10  * 
from	#t1 A left join #t2 B on A.ID = B.ID
where	B.ID is null
option (loop join,force order)

 /*вариант 2*/ 
select top  10  * 
from	#t1 A left join #t2 B on A.ID = B.ID
where	B.ID is null
option (hash join,force order)

drop table #t2
drop table #T1

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

id id
----------- -----------
1 NULL
3 NULL
5 NULL
7 NULL
9 NULL

id id
----------- -----------
7 NULL
5 NULL
3 NULL
9 NULL
1 NULL

@@version
Microsoft SQL Server 2000 - 8.00.534 (Intel X86)
Nov 19 2001 13:23:50
Copyright (c) 1988-2000 Microsoft Corporation
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 2)

Вроде бы как удалось получить при одном и том же (формально) запросе разный порядок данных в выборке
В принципе, чуть ранее я об этом и говорил
B.R. Alexey

...

Рейтинг:

0 / 0

02.09.2002, 20:23:43

| Ответить | Цитировать | Написать

35 сообщений из 35, показаны все 2 страниц

все

Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Рушится вера в

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=46&tid=1820674]:	0ms
get settings:	7ms
get forum list:	16ms
check forum access:	3ms
check topic access:	3ms
track hit:	43ms
get topic data:	10ms
get forum data:	2ms
get page messages:	70ms
get tp. blocked users:	1ms
others:	279ms

total:	434ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы