La idea es muy fácil y no es nueva.
Si necesitas hacer «delete/insert/update/alter» con enormes números de los datos o necesitas cumplir «alter» para la tabla enorme, tienes que cambiar la base de datos a «no logging» temporalmente.

0. Acabar todos los sesiones de usuarios
1. Hacer un backup
2. Crear symlink para "/dev/null"

ln -s /dev/null /dev/fakermt

3. Cambiar el parámetro TAPEDEV en onconfig (untape no le gusta /dev/null)

TAPEDEV /dev/fakermt

4. Cambiar la base a «no logging»

ontape -s -N dbname

5. Hacer el trabajo
6. Cambiar la base atrás(«buffered log» por ejemplo)

ontape -s -B dbname

7. Cambiar el parámetro TAPEDEV atrás

Собственно идея проста и далеко не нова.
Если есть необходимость произвести массовый delete/insert/update/alter с таблицей большого размера и есть возможность организовать небольшой downtime, то есть смысл временно перевести БД в режим «no log», произвести работы и вернуть всё обратно(если режим логирования ANSI, то способ работать не будет).

0. Глушим все пользовательские сессии
1. Делаем backup
2. Создаем симлинк для /dev/null

ln -s /dev/null /dev/fakermt

3. Меняем параметр TAPEDEV в onconfig (ontape «не любит» работать с /dev/null)

TAPEDEV /dev/fakermt

4. Меняем режим логирования базы

ontape -s -N dbname

5. Делаем свое чёрное дело
6. Меняем режим логирования обратно(в моем случае buffered log)

ontape -s -B dbname

7. Меняем обратно параметр TAPEDEV
8. PROFIT!!!

Понадобилось собирать статистику по нескольким метрикам с кучи lotus'овых серверов. По некоторым причинам стандартные методы применить не представлялось возможным. Сразу оговорюсь — хоть решение и рабочее, но применения так и не нашло. :]


Читать дальше

Перекосило агента, да так качественно, что стал он генерить критические сообщения быстрее, чем успевал отсылать, причем сыпал не в самую важную консоль ушедшему обедать дежурному. И нагенерил он их в итоге 70 тысяч с хреном минут за 40.
И все бы ничего, но… «Notification»


Читать дальше

Прежде чем “экономить” блокировки меняя lock mode с row на page – желательно убедиться, что row<page. :]

На сервере одновременно работают несколько инстансов oracle разных версий. С ними надо производить однотипные рутинные операции – возникает вопрос, как определить ORACLE_HOME необходимый для работы с конкретной БД.


Читать дальше

Имеем конфигурацию:
SLES 11
Apache/2.0.63
Informix Web datablade 4.13.UC3

Клиенту от веб-сервера приходит страница с испорченным хидером. Конкретно с полем content-type.

HTTP/1.1 200 OK
Date: Thu, 03 Dec 2009 09:07:54 GMT
Server: Apache/2.0.63 (Unix) DAV/2
content-type: ?X?P
Content-Length: 4097
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive

Читать дальше

Есть:
— шесть инстансов Informix
— разработчики, постоянно что-то внедряющие
— отсутствие у разработчиков привычки прогнозировать объем данных, сваливающийся в БД после внедрений

Всё это порождает два вида проблем — внезапное исчерпание свободного места в БД и таблицы, упершиеся в предел экстентов.

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


Читать дальше