Так случилось, что продукт, который мы разрабатываем работает с несколькими реляционными базами данных. Сейчас это MS SQL, Postgres и Oracle. Были запуски под много чем от MySQL до покойного, наверное, Firebird и экзотических Sybase с DB2, но сказ не об этом.
Если с MS SQL и Postgres все более мене понятное-привычное, то с Oracle каждый раз нас ждут какие-то сюрпризы. Проницательный читатель сразу заметит, что "руки у нас кривые" и мы "попросту не умеем его готовить", но если, уважаемому читателю захочется узнать чем varchar (а точнее varchar2) в Богоподобном Oracle отличается от его собратьев, то прошу под кат.
Я не админ, но иногда возникают задачи, которые проще (и интереснее) решать самому чем кому-то делегировать.
Изредка у нас появляется необходимость «поднять» servlet контейнер (чаще всего Apache Tomcat) и настроить для него проксирование, ssl termination (а проще говоря https) и все это прикрыть firewall'ом (оставив наружу только ssh и http/https).
Так получилось, что за последнюю неделю я эту задачу решал трижды (так стали звезды, а до этого — года два назад) и этот опыт трансформировался в сей небольшой опус.
Вот cсылка на официальный EOL от Oracle, в которой в разделе "Java SE Public Updates" черным по английскому говорится, что Java 9 будет поддерживаться до Марта 2018, а Java 8 — до Января 2019 (или позже) и Декабря 2020 (или позже).
Scala — это изумительный язык программирования, которым я наслаждался года 4 назад. Я, наверное, был его фанатом: покупал книги и курсы на Coursera, использовал в pet- и продуктивных проектах et cetera, et cetera, et cetera.
Scala открыл для меня увлекательный мир функционального программирования, вернул во времена студенчества со «сферическими задачами в вакууме» от Martin'a Odersky…
Но вот он уже года два как Scala для меня мертва. Виной этому…
История последних дней. Есть у нас два SQL Server'а (2016 c SSD диском) и Express Edition (2012 с традиционным HDD). Аппаратно оба компьютеры примерно похожи (CPU/RAM/LAN). В целом 2016 «отдает» данные в 2-5 раз быстрее, за исключением некоторого набора таблиц, для которых 2012 работает быстрее в 1,5-2 раза. Такое поведение полностью противоречит какой бы то ни было логике. Любые манипуляции с настройками базы данных только ухудшают ситуацию. 2016 все более замедляется, но только для этого набора таблиц.
Для понимания парадоксальности ситуации — на обоих серверах развернута одна и та же база (с одного и того же файла backup'a). В этой базе порядка 600 таблиц. Те 5-6 которые ведут себя удивительно ничем не отличаются от десятков подобных (по структуре и количеству записей) с которыми такой проблемы нет. На обоих «серверах» — Windows 10 с последними обновлениями (это сервера разработок, а не продуктивные). На обоих SQL Server'ах последние сервис паки (без hot fix'ов). Никакие специальные «режимы» (trace flags и пр.) SQL Server'ов не включены.
Загадка сия была велика, но мой коллега ее решил. Вы даже знаете как…