Entry tags:
Хроники пикирующего ораклоида
Продолжаю экстренное изучение мелкомягкого SQL-сервера и T-SQL. Открыл для себя много нового.
Нестандартность некоторых решений весьма впечатляет - авторы во многом шли ну очень своими путями. В поисках концентрированного описания отличий MS SQL от знакомых СУБД прошёлся по форумам sql.ru. Нашёл 60+ страниц срача о локальных временных таблицах, весьма познавательно ;)))
Нестандартность некоторых решений весьма впечатляет - авторы во многом шли ну очень своими путями. В поисках концентрированного описания отличий MS SQL от знакомых СУБД прошёлся по форумам sql.ru. Нашёл 60+ страниц срача о локальных временных таблицах, весьма познавательно ;)))
Родилась легенда
Собственно, вполне реальные события - ERP-система нашего клиента в ходе консолидации финансовых данных сгенерила SQL-запрос длиной 2 мегабайта примерно следующего вида:
select a,b,c from my_table
where a in (0000001,0000002,00000003,00000004,00000006,0000023...
и так далее.
Оракловый парсер изумился и выкинул белый флаг ORA-3113 (end of communication channel).
Оракл изумился действиям парсера и выкинул кору на 4.5 гигабайта.
Служба поддержки Oracle изумилась и ушла в астрал.
Интеграторы изумились и написали разработчикам.
Разработчики изумились и после 3-дневного размышления признали фичу багом...
Ну а по московскому Oracle-community теперь ходит байка про 2-мегабайтный SQL-запрос.
"Просмотрите, дети... Так писать НЕЛЬЗЯ!!!!!"
select a,b,c from my_table
where a in (0000001,0000002,00000003,00000004,00000006,0000023...
и так далее.
Оракловый парсер изумился и выкинул белый флаг ORA-3113 (end of communication channel).
Оракл изумился действиям парсера и выкинул кору на 4.5 гигабайта.
Служба поддержки Oracle изумилась и ушла в астрал.
Интеграторы изумились и написали разработчикам.
Разработчики изумились и после 3-дневного размышления признали фичу багом...
Ну а по московскому Oracle-community теперь ходит байка про 2-мегабайтный SQL-запрос.
"Просмотрите, дети... Так писать НЕЛЬЗЯ!!!!!"