Просто чтобы в голове не держать.
№1 - alter table

oracle 10.2.0.3
impdp схемы (на несколько гигов) с использованием remap_schema приводит к тормозам (более получаса) и падению процесса по out of memory (судя по всему в pga) в момент импорта статистики по таблицам. находил даже ссылку на баг в металинке... выход - указать exclude=statistics и потом ручками ее собрать после подъема дампа...

"Эволюция одного процесса"

Disclaimer
Все действующие лица выдуманы, все совпадения с реальностью случайны.

- Декорации и действующие лица
Фирма А. Есть некоторая система, в которой работают пользователи. Доработки и исправления ошибок идут постоянно, без привязки к версиям.
Разработчик Р
Аналитик А
Менеджер проекта М
Добрый пользователь ДП
Злой пользователь ЗП

- Действие 0.
ДП. "Ребята, у ват тут фигня какая-то. Посмотрите пожалуйстаЭ
Р. "Так, ага, тут у нас ошибочка. Сейчас мы ее поправим на рабочей базе"
М. Пребывает в блаженном неведении
Р. "Все, поправили, смотрите"
ДП. "Ага, спасибо. Но отвалилось теперь вот здесь"
Р. "Блин"
ЗП. "Ваша система говно! Ничего не работает! Я буду жаловаться!"

- Действие 1.
М. "Так. Теперь на каждое изменение на рабочей базе вы будете давать на подпись мне бумажку, в которой будет написано, что и зачем вы хотите поменять"
Р. "Yes, sir!"
ДП. "Ребята, а сделайте вот такую вот фишку.."
Р. "Ага, сейчас, сделаем. Только одну бумажку напишу, и на подпись менеджеру"
Р. - М. "Вот, принес бумажку."
М. "А это что? А зачем? Надо? Ну ладно, делай..."
ДП. "Ребят, а вы меня не так поняли... Я то хотел с перламутровыми пуговицами..."
Р. "Блин"

- Действие 2.
М. "Так, Теперь на любое изменение на бумажке должна быть подпись аналитика, и подпись пользователя, что они это протестировали, и согласны"
Р. "Yes, sir!"
Р. - М. "Вот, принес бумажку. И вот пользователь со всем согласен"
М. "Молодец, давай, выкладывай"
ЗП. "АААА!!! Вы опять все сломали!!! Я буду жаловаться!!!"
М. - Р. "Чё за фигня?"
Р. "Ну это, когда выкладывал, я там пару файлов с теста забыл перенести..."
М. "Все, процесс выкладывания на прод закрываем для разработчиков. А ну быстро забыл пароли! Теперь этим будут заниматься специально обученные люди"
Р. "Yes, sir"

- Действие 3.
ДП. "Ребят, а у вас теперь фигня в другом месте вылезла"
Р. "Мда. Прохлопали"
М. "Так. Раздолбаи. Вредители. Вводим систему баллов. Принес бумажку - +1 балл, после бумажки что-то сломалось - тебе и тестеру по -3 балла. Уйдете в минуса - ай-яй-яй"
Р. - А. "А подпиши бумажку. Задача плевая, дело верняк"
А. "Ок. Неси еще пару простых, баллы зарабатывать нужно"

- Действие 4.
Р. - М. "Вот, принес бумажку. Все подписи, красота"
М. "Угумм. Хммм. А как тестировали?"
Р. "Ну... Это А. тестировал, что то там проверили..."
А. "Ну... Это, там щелкнул, что то вылезло, тут что-то посчиталось..."
М. "Раздолбаи! Теперь к каждой бумажке будете готовить еще одну бумажку, где будет написан подробный тест-план"
Р. "Yes"

- Действие 5.
М. "Таак. Это че? Где документация на код, я тебя спрашиваю! Я те дам самодокументирующийся код! Без документации на доработку никаких подписей!"
Р. (тяжело вздыхая) "..."

Действие 6.
ДП. "Ребята, произошла срочная фигня, работа встала!!!"
Р. "Ага. понятно. Исправлений там на 5 минут. Через 4 часа все будет исправлено"
ДП "4 часа??? Почему так долго???"
Р. "Ну так это, бумажки писать, подписи собирать..."
Р. "А, сегодня же пятница. Ну тогда до понедельника, в пт. менеджер бумажки не подписывает"
ДП. рычит и превращается в ЗП. "ААА!!! У вас ничего не работает!!! Я буду жаловаться!!!"

- Действие n.
ДП. "Ребят, а у вас вон там фигня."
Р. "Знаем, заводите задачу, пишите бумагу."
ДП. "У... Этим же надо заниматься. Ладно, обойдусь как нибудь без вас..."
ЗП. "ААА!!! У вас ничего не работает!!! Я буду жаловаться!!!"
Р1. - Р. "Слушай, а у нас ведь там фигня, и все скоро сломается"
Р. "Знаю. Но так ведь это надо задачу заводить, пробивать, бумажки писать... Ну нафиг. Сломается - починим"

Вот. Завтра исполняется 3 недели с того "прекрасного" момента, как офис банка, в котором я имею честь сидеть на проекте, переехал в Химки. Пришлось из беззаботного пешехода переквалифицироваться в озабоченного водителя :) Ну а также сменить машинку, ибо регулярно ездить на азлыке удовольствия не доставяет. Это вам не раз в неделю на дачу потерпеть.
По времени доставка тела с утра к 8 часам занимает примерно минут 35-40, обратно минут 50. Не сильно хуже предыдущих мест работы. Если ехать общественным транспортом, выходим 1ч 40 мин.
Офис типа класса А+. Ага. По слухам, это первый опты Икеи в построении бизнес-центра. Так что бета-версия. Жрать ходим в Мегу через дорогу. 15-20 минут в одну сторону пешком. Ибо столовая внизу по слухам это дорого и не особо вкусно.
По общему заключению сотрудников, самое плохое в этом офисе - кресла. Блин, испанская инквизиция отдыхает.
Вот. Проект продолжается. Но желания работать на этом проекте, а главное силы воли уже практически не хватает. Все благодаря одному человеку. Вроде бы я и человек спокойный. Но вот нет, достало конкретно. Жаль, но похоже надо будет стряхнуть пыль, освежить в памяти боевые заслуги, и оглядеться вокруг себя. Жаль конечно фирму, она не виновата в том, что один из клиентов неадекватен, но не уверен, что смогу добиться перевода на другой проект. Да и хочется ли мне этого? В общем, хотя говорят и кризис на дворе, но ситуация меня конкретно заебала.

Ну и напоследок маленькое напоминание самому себе. мониторить базу и состояние объектов на валидность надо постоянно. Первое, что должен сделать правильный админ или DBA - настроить полный мониторинг системы под себя. Надо будет собрать воедино пачку недоделанных своих скриптов, и привести их в порядок. А то надежды, что тут заработает система мониторинга, как то призрачны. Спасение утопающих - дело рук самих утопающих :)

Вот, если предыдущий пост был про прослеживание взаимосвязей "культурным" путем, этот про археологические раскопки :)
Была тут недавно дискуссия на тему, чем кошернее собирать витрины в хранилище - ETL средствами, или средствами самой СУБД. После прослеживания путей растекания данных по хранилищу без участия документации, должен заметить, что у сборки средствами СУБД, есть один большой плюс - легко прослеживаются зависимости и преобразования. Чего не скажешь о ETL, который по сути своей - черный ящик, и автоматизированной обработке поддается весьма плохо, если не сказать отвратительно. Есть конечно исключения, типа SASa, где весь код можно выгрузить и просмотреть, но ведь у нас и не SAS используется :(
ЗЫ: На железный аргумент - а надо писать документацию в полном объеме, мне ответить нечего :) Я полностью согласен, что лучше быть богатым и здоровым :)

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

Копался тут с одной базой, которой внезапно стало плохо... Там много всего, но одно уж очень хочется подчеркнуть, ибо сталкивался уже неоднократно. Любой вызов функции в SQL запросе - полусгнившая бомба замедленного действия. Может и не выстрелить, но скорей всего рванет так что мало не покажется. Причем потенциальной засады, если анализируешь только план выполнения запроса, обычно и не видно, т.к. стоимость ее выполнения там не показана... Нужно гнать через trace/tkprof, там всплывает много интересного :) Помню один клинический случай - результат сравнения результатов выполнения функций был условием join'a. На совсем небольшой базе функция успел вызваться за короткий промежуток времени 1 500 000 раз :) Сервер наверное ее уже в лицо узнавал :)
Так что господа - абстракция конечно вещь хорошая, но если есть возможность преобразовать в подзапрос, а еще лучше, тупо присоеденить еще одну табличку, сделайте это. Сервер вам спасибо скажет :)

Решил тут я выкачать архив своей почты с gmail на свой локальный винт. Выкачал. И вот в процессе разгребания почты за 4 года, подумалось, а имеет ли вообще информация в архиве хоть какую-то ценность для меня? И вообще, пойдя дальше, что в информационном потоке, который ежедневно протекает сквозь нас, имеет ценность, которая не девальвирует через неделю?
К сожалению (а может быть и к счастью), никак у меня не получается консолидировать всю проходящую через меня информацию в одной точке. Да хотя бы потому что используется несколько компьютеров, они меняются, меняются места работы... И вот такого, чтобы собрать почту, переписку по IM, все закладки, ebooks, заметки, куски кода в одном месте - ну не получается. Хотя можно конечно, если поставить себе такую цель.
А теперь возник вопрос - да и стоит ли консолидация и сохранение каких-либо усилий?
Особенно если рассматривать это не на короткой перспективе, например год, а посмотреть издалека, что из информации, которая лежит сейчас, потребуется через 2-3 года? Или же что из информации, которую я собирал 2-3 года назад, сейчас нужно мне? Похоже, что НИЧЕГО.
Технологии меняются, личные архивы используются только при приступах ностальгии.
Действительно важные данные должны находиться в голове. Понимание концепций, опыт, ключевые слова. А кратковременный мусор периодически вымывается, ну и фиг с ним.
В накоплении информации очень много субъективного, иногда она ощущается как вещь, с которой жалко расстаться. Но думаю что возможно. Достаточно провести мысленный эксперимент. Представьте, что вы начинаете новую жизнь. Новая работа, с чистым компом, домашний комп отформатирован, логины и пароли на все сервисы забыты (почта, аська, букмарки, ...), мобильник выкинут. Все, информация только та, что есть в голове. Наступила ли катастрофа? Надеюсь что нет.

ЗЫ: Пока писал, вспомнил про архив фотографий. Дело конечно приятное, рассматривать фотки из отпуска 4 года назад, но вот честно, имхо все эти просмотры нужны только если пришли гости, и их нечем занять до подачи горячего :))

http://blog.not-a-kernel-guy.com/2008/12/16/395
а я тут блин понимаешь переживаю над дуростью нашего ББ... По сравнению с гениальными идеями по ссылке это так, фантики... Ну подумаешь новая система именования объектов, когда проект уже на саппорте... будем писать tzx101_operation.cop_pk вместо существующего operation.op_id, и так во всем... Пох... И Нах... Даешь другой проект... уж лучше кипящий бардак, но где можно взять ответственность на себя и делать так, как считаешь нужным без такой опеки...
все, взмахнули рукой и расслабились...
боролся тут с забавным глюком... 2 сервера, почти похожих. на обоих стоит websphere, из-под которой запускается batch через runtime.exec
Так вот, на одном из серверов, при запуске одного специфичного exe, ничего не происходило, в отличии от второго, где все отрабатывало замечательно
первое. товарищи, вычитка выходных потоков дочернего процесса обязательна... а то понимаешь ли, подвисает процесс, ждет когда буфер почистят... Причем до какого то объема batch файла это незаметно (если не стоит echo off), а потом начинается...
и второе. надежнее формировать переменные окружения самому, в batch файле, потому как неизвестно, откуда и как вас будут запускать... потому что пришлось идти через straceNT, чтобы понять, что exe сваливается с exception (код забыл), когда не может найти какую-то dll... Вот почему на одном сервере находит, а на другом нет - хз, параметры запуска я сравнивал... прописал %PATH%, и успокоился...

Развлекаюсь с небольшим симпатичным дистрибутивом. CRUX. Инициализация в BSD стиле, порты опять почти как в FreeBSD. При установке минимум, далее все ручками.

Установка ничем особым не отличается для дистрибутивов такого направления, загрузка с boot cd, разметка диска, chroot на размеченный диск, первоначальная настройка rc.conf и сетки, сборка своего ядра, установка lilo/grub, перезагрузка...
Если не угадали с модулями ядра, то повторный процесс :)

Не забыть сразу в /etc/ports добавить contrib, gnome, kde, xfce репозитории портов, список на сайте

ports -u чем раньше тем лучше обновить дерево портов
prt-get diff разница между версией в port и установленной
prt-get sysup махом все обновить
prt-get depinst - это чтобы порты сразу с зависимостями

как обустрою рабочую среду, продолжение следует...

"Когда в руках молоток, все вокруг кажется гвоздями"...
А вот когда в руках совковая лопата...

Интересно, каково было бы Гераклу, если бы подвиг по вычистке Авгиевых конюшен ему пришлось бы повторять постоянно, вместо остальных 11ти подвигов?

NB. а не пора ли вам сударь, обновить свой рекламный щит и встать у дороги?

- Здравствуйте, я бы хотел заказать у вас садовую скамейку. Знаете, обычную такую, пара досок поперек, и спинка.
- Замечательно, что вы обратились именно к нам. Давайте, мы разработаем чертежи скамейки, приходите через неделю.
... прошла неделя...
- Здравствуйте, я насчет скамейки...
- Замечательно что вы пришли. Смотрите, у нас получился замечательный диван в викторианском стиле. Сейчас мы заняты тем, что рассчитываем толщину пуленепробиваемого стекла, стена из которого будет окружать ваш диван.
- Э... минуточку, мне нужна обычная садовая скамейка, ничего более...
- Мы все понимаем, не волнуйтесь. Вот, не могли бы вы взглянуть на эту электрическую схему? Она позволяет вам дистанционно управлять углом наклона спинки дивана. Правда здорово?
- Но мне нужна была всего лишь скамейка...
- Мы специалисты в своем деле, не волнуйтесь. Мы можем предугадать ваши дальнейшие потребности, и заложить механизмы реализации уже прямо сейчас. Как вам идея сделать вместо ножек у дивана гусеницы? Это поможет вам передвигаться на нем по пересеченной местности...
- Да я... Просто хотел поставить ее во дворе, чтобы бабушкам было на чем сидеть...
... хватает топор...

Вот, немножко начал игратся с distributed cvs, т.к. до этого опыта никакого с ними не имел. Далее просто неформальное изложение мыслей, чтобы потом не потерялось...
Итак, начинаем играться с mercurial. Почему именно оно, а не darcs или git? Не знаю, честно говоря, просто в памяти отложился.
Итак, начинаем тихие игры. Самый лучший кандидат на контроль версий в linux системе имхо это /etc :) С него и начнем. Нам нужно создать 2 репозитория (можно обойтись и одним, но зачем тогда dcvs? :) ).
1-й, типа удаленный. Для простоты делаем его в домашнем каталоге.
mkdir -p ~/repo/etc
cd ~/repo/etc
hg init
Создали каталог и проинициализировали репозиторий.
Далее уже под root идем в /etc
cd /etc
hg init
hg add
hg commit -m "initial revision"
Проиницализировали типа локальный репозиторий, добавили в него файлы, и закоммитили в локальный репозиторий.
При коммите пишем текст сообщения, иначе по-любому поднимется редактор и заставит его написать :)
В процессе можно поиграться с
hg status - выводит статус файлов в директории относительно хранящихся в локальном репозитории
hg log - показывает лог коммитов
Теперь отправляем файлы из "локального" в "удаленный" репозиторий (иожно делать и под обычным пользователем)
cd /etc
hg push ~/repo/etc
И получаем их в "удаленном" репозитории
cd ~/repo/etc
hg update

В общем, как я понял, идеология поощряет использование отдельных репозиториев на каждый бранч (путем hg clone), правки там, и потом hg push в родительский, с периодическим выполнением hg poll для обновления содержимого локального репозитория

Видимо после небольшого перенапряжения на текущем проекте начали меня посещать несообразные мысли об альтернативном пути в жизни - т.н. downshifting... Ну типа там свалить в Гоа, питаться бананами, и ничего не делать. Как щадящий вариант с минимумом изменений - пользуясь бумом спроса на программистов, свалить куда-нибудь обычным рядовым программистом клепать формочки и запросы, по вечерам выходя в космос и общаясь с астралом. Звучит все это черезвычайно заманчиво, удачно вписываясь в анекдот про негра и сбор бананов.
К чему это я все написал? Честно говоря не знаю, просто захотелось структурированно изложить кашу, которая сейчас крутится у меня в голове, авось заодно и смысл жизни найдется, и тогда глупые вопросы перестанут возникать.

ЗЫ: А вот неудобно иногда, что в OCaml по умолчанию string <> char list, и нужно писать преобразование ручками. Или это я такой невнимательный? :)

Читаю сейчас замечательную книжку Leo Brodie "Thinking Forth" (ссылка)
Несмотря на то, что книга выпущена в 1984 году, актуальности своей она не потеряла. Читаю, и все больше убеждаюсь в корректности изречения "Все новое - это хорошо забытое старое".

Создание DSL как основной способ решения задач.
Быстрые итерации, прототипирование, постоянное взаимодействие с пользователем - основные постулаты Agile методик.

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

"Структура банковских данных слишком сложна, чтобы применять к ней правила реляционного моделирования" - шедевральная цитата, взята из обсуждения здесь.
Это я к тому, что все виденные мной схемы БД для банков, действительно выглядят несколько "лохмато". Широкие таблицы, куча редкоиспользуемых колонок, дублирующихся значений, смешение различных сущностей в одной таблице... Все это в той или иной степени присутствует во всех виденных системах. Похоже, что либо все архитекторы придерживаются этой максимы, либо таков неумолимый эволюционный процесс, что любая схема БД со временем накапливает энтропию и деградирует до 1НФ (или в лучшем случае до 2НФ)?

В очередной раз перечитываю "Путь камикадзе" Йордона. До чего же хорошая, успокаивающая и умная книжка... Просто сейчас вживую наблюдаю все то, что написано в книжке, точность попадания и систематизации просто поражающая....

Интересно, какое название лучше подойдет - некропрограммист или археолог-программист? Не хочу ни так, ни так на самом деле...

Еще несколько наблюдений из разряда типовых задач для баз данных. Итак, времязависимые данные. Есть 2 основных подхода для хранения периода актуальности у сущности:

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

- EntityPK, ValidFrom, ValidTo. В этом случае все ровно наоборот - простота выборки и сложность добавления и поддержания согласованности данных.

Кроме чистого подхода, можно например оптимизировать первый вариант для наиболее часто встречающегося случая - запрос актуальных данных на текущую дату, путем добавления поля-признака isActualState. Вариантов реализации много, от триггера до materialized view.

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

Здесь неполный список того, что хотелось бы видеть от этого типа даных.
- Задание даты начала, даты конца. Поддержка +/- бесконечности
- Получение длительности.
- Возможность арифметических действий - сложение, вычитание, пересечение, проверка на равенство.
- Проверка вхождения даты в интервал
- Возможность построения индекса по полям данного типа
- Проверка интервала на уникальность (что нет пересечений с другими значениями данного поля)
- Поддержка NULL-значений