JP Morgan Chase Oracle database outage

[IvanGrozniy]

Я тут напоролся на пример в MS SQL:

WHERE YEAR(recorddate) = YEAR(getdate())

Приведенный индукод выбирает записи текущего года
Как оказалось, SQL его индексирует
Видимо слишком много встречался

А не индукод, это как? Небось WHERE CAST(recorddate AS VARCHAR(4)) = CAST(getdate() AS VARCHAR(4))

[Dmitry67]

Не индукод это

WHERE recorddate>=convert(datetime,left(convert(varchar,getdate()),4)+'0101')

ugly, но правильно
главное чтобы колонки были вне каких либо функций
Представьте что написано

WHERE MyFunc (recorddate) = 'flagged'

Можете ли вы, не зная, что делает MyFunc понять, какие даты нужно выбирать?
Я нет. SQL тоже
Функцию YEAR прописали ручками специально

[mynameiszb]

Предлагаю разобрать пару-тройку примеров сношения с zOS.

И подставить людей, которые поделились со мной закрытой информацией. Не уж..

Про DB2 из "публичного", могу вспомнить эпопею с Питерским Сбером. Когда год вели пилотный проект с переспективой перетащить все на диби-ту. Убили кучу консультантского времени, железо туда-сюда возили и настраивали.

После чего сказали "у вас Оракл неправильный" и гордо ушли, не сумев портировать систему с одной базы на другую. Мерло оно не под Ораклом. Под не пиковой нагрузкой. И никакие громкие слова про супер-стабильную базу на супер-стабильном железе не помогали.

PS. Дабы не разводить флейм, я повторюсь: в грамотных руках работает любая софтина. Остроенная, заточенная и обихоженная. У друга сейчас на 40 террабайтной базе запросы летают просто со скростью поросячьего визга. Потому как думали, проектировали и тюнили с умом. И я более чем уверен, что доверь это бангалорским братьям, система бы встала в позу уже на сотни гигов. Потому как думать надо, а не левые скилы в резюме рисовать.

Поэтому сворачиваюсь

Т.к. - заскорузл и слишком стар, чтобы в холиварах участвовать...

[zVlad]

Предлагаю разобрать пару-тройку примеров сношения с zOS.

И подставить людей, которые поделились со мной закрытой информацией. Не уж..

.....

Ерунда какая то право дело. Проблемы zOS не могут быть закрытой информацией, это совершенно не секретная система и у меня например есть доступ к любым ее проблема. Мне лишь хотелось узнать с чем можно сношаться в zOS, потому что за много лет работы я ничего такого сношабельного в zOS не встречал (за исключением некоторых аспектов USS, которые не выходят за рамки обще-Юниксовских).

[zVlad]

...
Т.к. - заскорузл и слишком стар, чтобы в холиварах участвовать...

Нет уж дорогой. Сказал "А" скажи и "Б", а иначе это булшит по-русски называется. Пример с Питерским Сбером тоже не впечатляет. Больше похоже на реакцию обиженного ребенка, которому купили машинку с некрутящимися колесикам.

P.S. Не думаю что Вы старше меня. Мне 55.

[IvanGrozniy]

Не индукод это

WHERE recorddate>=convert(datetime,left(convert(varchar,getdate()),4)+'0101')

ugly, но правильно
главное чтобы колонки были вне каких либо функций
Представьте что написано

WHERE MyFunc (recorddate) = 'flagged'

Можете ли вы, не зная, что делает MyFunc понять, какие даты нужно выбирать?
Я нет. SQL тоже
Функцию YEAR прописали ручками специально

Ну так и приведите исходники этой функции, что гадать-то. Если MSSQL индекс динамически создает, то самописная функция YEAR возможно в полном порядке. Может быть внутри этой функции стоит что-то наподобие родной функции от MSSQL DATEPART?
Мое мнение, что ваш код WHERE recorddate>=convert(datetime,left(convert(varchar,getdate()),4)+'0101') еще хуже индокода, он не будет нормально работать, например, для 2005-го года. Вместо 2005 года выдаст и 2006, 2007, 2008, 2009, 2010 года.
Удачи!

[zVlad]

как Вы наверное понимаете напрочь исключающий использование индексов.

Почему? Будет обычный index range scan вроде

Вот именно вроде. В DB2 это называется Stage 2 предикат. Т.е. применяется на уже выбранные из БД строки.

[Dmitry67]

Не индукод это

WHERE recorddate>=convert(datetime,left(convert(varchar,getdate()),4)+'0101')

ugly, но правильно
главное чтобы колонки были вне каких либо функций
Представьте что написано

WHERE MyFunc (recorddate) = 'flagged'

Можете ли вы, не зная, что делает MyFunc понять, какие даты нужно выбирать?
Я нет. SQL тоже
Функцию YEAR прописали ручками специально

Ну так и приведите исходники этой функции, что гадать-то. Если MSSQL индекс динамически создает, то самописная функция YEAR возможно в полном порядке. Может быть внутри этой функции стоит что-то наподобие родной функции от MSSQL DATEPART?
Мое мнение, что ваш код WHERE recorddate>=convert(datetime,left(convert(varchar,getdate()),4)+'0101') еще хуже индокода, он не будет нормально работать, например, для 2005-го года. Вместо 2005 года выдаст и 2006, 2007, 2008, 2009, 2010 года.
Удачи!

Если у вас в таблице есть будущие даты, то добавьте еще условие
Жаль что вы не понимаете сути проблемы

Что условие, грубо говоря

WHERE TAN(x)=0.5

индексируемо только если SQL сервер умеет для произвольной функции находить ARC-фунцию, ей обратную то есть вместо TAN(x)=0.5 искать x=ARCTAN(0.5)
мне стоит объяснить, почему x=ARCTAN(0.5) принципиально проще для поиска чем TAN(x)=0.5 ?

[crypto5]

как Вы наверное понимаете напрочь исключающий использование индексов.

Почему? Будет обычный index range scan вроде

Вот именно вроде. В DB2 это называется Stage 2 предикат. Т.е. применяется на уже выбранные из БД строки.

Если нету отягощающих обстоятельств, то этот запрос будет совершенно точно транслироваться в оракле в index range scan, то есть ваше утверждение что индексы здесь не применимы - неправильно.

[IvanGrozniy]

Не индукод это

WHERE recorddate>=convert(datetime,left(convert(varchar,getdate()),4)+'0101')

ugly, но правильно
главное чтобы колонки были вне каких либо функций
Представьте что написано

WHERE MyFunc (recorddate) = 'flagged'

Можете ли вы, не зная, что делает MyFunc понять, какие даты нужно выбирать?
Я нет. SQL тоже
Функцию YEAR прописали ручками специально

Ну так и приведите исходники этой функции, что гадать-то. Если MSSQL индекс динамически создает, то самописная функция YEAR возможно в полном порядке. Может быть внутри этой функции стоит что-то наподобие родной функции от MSSQL DATEPART?
Мое мнение, что ваш код WHERE recorddate>=convert(datetime,left(convert(varchar,getdate()),4)+'0101') еще хуже индокода, он не будет нормально работать, например, для 2005-го года. Вместо 2005 года выдаст и 2006, 2007, 2008, 2009, 2010 года.
Удачи!

Если у вас в таблице есть будущие даты, то добавьте еще условие
Жаль что вы не понимаете сути проблемы

Что условие, грубо говоря

WHERE TAN(x)=0.5

индексируемо только если SQL сервер умеет для произвольной функции находить ARC-фунцию, ей обратную то есть вместо TAN(x)=0.5 искать x=ARCTAN(0.5)
мне стоит объяснить, почему x=ARCTAN(0.5) принципиально проще для поиска чем TAN(x)=0.5 ?

У вас-то хоть индексы по полю recorddate присутствуют? А то про тангенсы заговорили

[Dmitry67]

Разумеется
Задача как раз в том чтобы индекс использовался, как я и писал в первом посте
а в общем случае выражения типа ВЫРАЖЕНИЕ ( колонка ) не индексируются

[IvanGrozniy]

Не индукод это

WHERE recorddate>=convert(datetime,left(convert(varchar,getdate()),4)+'0101')

Хотел протестировать на скорость и написал

select COUNT(*) from MyTable where created > convert(datetime, left(convert(varchar, getdate()), 4)+'0101')

Выдал ошибку The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.

Пошел дальше и поправил

select convert(varchar(11), getdate())

Получил

Sep 20 2010

Понятно уже да к чему я?

select left(convert(varchar(11), getdate()), 4)

Выдал вместо года

Sep

По крайней мере у ваших индусов код работает

[zVlad]

как Вы наверное понимаете напрочь исключающий использование индексов.

Почему? Будет обычный index range scan вроде

Вот именно вроде. В DB2 это называется Stage 2 предикат. Т.е. применяется на уже выбранные из БД строки.

Если нету отягощающих обстоятельств, то этот запрос будет совершенно точно транслироваться в оракле в index range scan, то есть ваше утверждение что индексы здесь не применимы - неправильно.

Индексы в DB2 - это не совсем то же что в Оракл. Индекс в DB2 дает, кратко говоря, прямой адрес памяти на дисках где хранятся искомые данные. Сам индекс тоже ищется на дисках с использованием аппаратного поиска, и в этом аппартном поиске не будет обрабатываться выражение из колонок, тем более если в выражение входят и индексированные колонки и не индексированные. Вы делаете смелые утверждения даже не уточнив все ли колонки в выражении предиката индексированны.
Я допускаю что в Оракл под видом индексированного доступа выполняется такая же работа как и в DB2 в Stage 2. Насколько мне известно Оракл не различает предикаты по признаку выполним он с использованием возможностей поиска дисков или нет. А DB2 различает и очень четко. Это целая теория.

P.S. Вот Dmitry67 примерно об этом же говорит парралельно нашей с Вами дискуссии.

[crypto5]

как Вы наверное понимаете напрочь исключающий использование индексов.

Почему? Будет обычный index range scan вроде

Вот именно вроде. В DB2 это называется Stage 2 предикат. Т.е. применяется на уже выбранные из БД строки.

Если нету отягощающих обстоятельств, то этот запрос будет совершенно точно транслироваться в оракле в index range scan, то есть ваше утверждение что индексы здесь не применимы - неправильно.

Индексы в DB2 - это не совсем то же что в Оракл. Индекс в DB2 дает, кратко говоря, прямой адрес памяти на дисках где хранятся искомые данные. Сам индекс тоже ищется на дисках с использованием аппаратного поиска, и в этом аппартном поиске не будет обрабатываться выражение из колонок, тем более если в выражение входят и индексированные колонки и не индексированные. Вы делаете смелые утверждения даже не уточнив все ли колонки в выражении предиката индексированны.
Я допускаю что в Оракл под видом индексированного доступа выполняется такая же работа как и в DB2 в Stage 2. Насколько мне известно Оракл не различает предикаты по признаку выполним он с использованием возможностей поиска дисков или нет. А DB2 различает и очень четко. Это целая теория.

P.S. Вот Dmitry67 примерно об этом же говорит парралельно нашей с Вами дискуссии.

Я не понимаю проблему, в оракле вы можете сделать function based индекс, и ваш запрос как я уже говорил будет использовать этот индекс. В ДБ2 вы можете построить такую же штуку с помощью тригеров, то есть везде можно и нужно использовать индексы в подобных ситуациях.

[Dmitry67]

IvanGrozniy, я же код не тестировал набивал сразу
Вот тестируйте

convert(datetime,left(convert(varchar,getdate(),102),4)+'0101')

указал формат 102