Каморка

Есть таблица t1, которую могу квери: select fld from t1
Есть также таблица t2, которую могу квери: select fld from t2

Не могу выполнить (из СКЛ аналайзер ): select T2.* from tbl2 T2, tbl1 T1 where T2.fld = T1.fld

DBCC updateusage не выдаёт ошибок.
DBCC checkdb ('MyDB', REPAIR_REBUILD ) не помогает.

Не работает даже если, как оказывается, в таблице tb1 содержится только одна запись.

Что чинить стал бы опытный дба?

Что значит не работает?
Пустой резалт-сет? или ошибка?
t1 inner join t2 работает?

Кажется DBA тут не помогут.
Наслько мне подсказывает опыт, подобная ситуация может быть
(если пустой резалт-сет) только если T2.fld нигде неравно T1.fld
Пробуй так сравнить

rtrim(ltrim(T2.fld )) = rtrim(ltrim(T1.fld ))

если есть лидрующие иле в хвосте пробелы (или невидимый символ)
то оно несравнится никогда

Кстати, как описаны поля?

такие вопросы надо задавть с примерами create table и с конкретной ошибкой и конкретно что ожидается в ответе.... какой вопрос такой ответ.

Ошибка - или таймаут, или ждём таймаута до посинения.
В таблицах нет ничего особенного. Тип поля char(4).

Oleksandr писал(а):Кажется DBA тут не помогут.
Наслько мне подсказывает опыт, подобная ситуация может быть
(если пустой резалт-сет) только если T2.fld нигде неравно T1.fld
Пробуй так сравнить

rtrim(ltrim(T2.fld )) = rtrim(ltrim(T1.fld ))

если есть лидрующие иле в хвосте пробелы (или невидимый символ)
то оно несравнится никогда

Кстати, как описаны поля?

Вопрос именно к DBA. Это была работающая годы база. Гарантируется, что в обеих таблицах имеются одинаковые значения поля fld char(4).
Вопрос из разряда рековери и траблшутинга.

ПС. для уменьшения неопределённости я удалил индексы, первичные и фореин ключи в обеих таблицах.

vg писал(а):

Oleksandr писал(а):Кажется DBA тут не помогут.
Наслько мне подсказывает опыт, подобная ситуация может быть
(если пустой резалт-сет) только если T2.fld нигде неравно T1.fld
Пробуй так сравнить

rtrim(ltrim(T2.fld )) = rtrim(ltrim(T1.fld ))

если есть лидрующие иле в хвосте пробелы (или невидимый символ)
то оно несравнится никогда

Кстати, как описаны поля?

Вопрос именно к DBA. Это была работающая годы база. Гарантируется, что в обеих таблицах имеются одинаковые значения поля fld char(4).
Вопрос из разряда рековери и траблшутинга.

ПС. для уменьшения неопределённости я удалил индексы, первичные и фореин ключи в обеих таблицах.

план запроса покажи. и скажи сколько записей реально должно возвращаться по запросу.

vg писал(а):...Это была работающая годы база. ...
ПС. для уменьшения неопределённости я удалил индексы, первичные и фореин ключи в обеих таблицах.

на основании этого можно предположить что таблицы большие и без индексов конечно будет тайм аут. А еще - если много общих значений, то может получится слишком большой ризалт сет.
Попробуйте сделать индексы по полям fld в обеих таблицах и сделать типа так:
select DISTINCT T2.* from tbl2 T2, tbl1 T1 where T2.fld = T1.fld
или (не очень хороший вариант, но можно попробовать, но только после создания индексов)
select T2.* from tbl2 T2 where T2.fld in (select fld from tbl1 T1)
и еще надо посмотреть - не отключен ли сбор статистики по этим таблицам.

ir писал(а):

vg писал(а):...Это была работающая годы база. ...
ПС. для уменьшения неопределённости я удалил индексы, первичные и фореин ключи в обеих таблицах.

на основании этого можно предположить что таблицы большие и без индексов конечно будет тайм аут. А еще - если много общих значений, то может получится слишком большой ризалт сет.
Попробуйте сделать индексы по полям fld в обеих таблицах и сделать типа так:
select DISTINCT T2.* from tbl2 T2, tbl1 T1 where T2.fld = T1.fld
или (не очень хороший вариант, но можно попробовать, но только после создания индексов)
select T2.* from tbl2 T2 where T2.fld in (select fld from tbl1 T1)
и еще надо посмотреть - не отключен ли сбор статистики по этим таблицам.

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

тяжело советовать без ddl и не зная какие и сколько данных в таблице.
distinct заставит движок выполнить stream aggegate что только усугубит дело. Можно проигнорировать для начала result set и попросить вернуть только count(*) что бы убедиться что записи есть. Посмотреть бы ожидаемый план и для внутренней таблицы прикинуть что дешевле - скан или index seek, тогда в последнем случае создать индекс на join column, кластерный. Для outer table судя по запросу всегда будет скан. Если есть clustered index, тогда скан по IAM pages может оказаться быстрее, поэтому можно поставить nolock либо tablock hint на эту таблицу.
Не зная всех деталей, это так, совет вслепую

Похоже, ключевые слова - рекавери и траблшутинг не прочитаны. Эти таблицы убитой базы - мизерные. Каждая из таблиц может содержать 10 и даже одну запись. Вопрос не в производительности. Вопрос в невозможности выполнить join на этих двух таблицах в принципе.

vg писал(а):Похоже, ключевые слова - рекавери и траблшутинг не прочитаны. Эти таблицы убитой базы - мизерные. Каждая из таблиц может содержать 10 и даже одну запись. Вопрос не в производительности. Вопрос в невозможности выполнить join на этих двух таблицах в принципе.

база в каком состоянии? вообще из таблиц ничего прочитать не можешь? бакап базы есть? бакап хвоста лога сделал?

папа Карло писал(а):

vg писал(а):Похоже, ключевые слова - рекавери и траблшутинг не прочитаны. Эти таблицы убитой базы - мизерные. Каждая из таблиц может содержать 10 и даже одну запись. Вопрос не в производительности. Вопрос в невозможности выполнить join на этих двух таблицах в принципе.

база в каком состоянии? вообще из таблиц ничего прочитать не можешь? бакап базы есть? бакап хвоста лога сделал?

То что в продакшн восстановлено из бекапа - сейчас работает нормально.
Здесь же речь идёт о базе, которую убили on a fly.

Сравнение структуры этих таблиц, включая индексы и прочее показывает, что внешне всё одинаково.

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

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

vg писал(а):

папа Карло писал(а):

vg писал(а):Похоже, ключевые слова - рекавери и траблшутинг не прочитаны. Эти таблицы убитой базы - мизерные. Каждая из таблиц может содержать 10 и даже одну запись. Вопрос не в производительности. Вопрос в невозможности выполнить join на этих двух таблицах в принципе.

база в каком состоянии? вообще из таблиц ничего прочитать не можешь? бакап базы есть? бакап хвоста лога сделал?

То что в продакшн восстановлено из бекапа - сейчас работает нормально.
Здесь же речь идёт о базе, которую убили on a fly.

Сравнение структуры этих таблиц, включая индексы и прочее показывает, что внешне всё одинаково.

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

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

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

[quote="папа Карло]
надо четко знать что делали...[/quote]
Ты думаешь, что тогда бы я спрашивал?
Я не знаю, кто и что делал в тот момент. Там около десятка девелоперов, кто имеет почти неограниченный доступ.