Сеп. 072009
 

В събота се случи нещо много тъжно. 15 невинни българи загинаха по нелеп начин в охридското езеро. Мир на душите им.

В неделя пловдивският митрополит, „дядо“ Николай, вместо да изпълни една от основните функции на църквата – да успокои опечалените близки на загиналите – загатна, че това е божие наказание за концерта на Мадона. Концерта, срещу който същият този Николай възропта.

Висшият клир на българската православна църква отдавна е твърде далеч от своите миряни. Не мога да кажа дали е близо до бога, но всичките техни ежби и ламтене за имоти ме карат да мисля, че за тях църквата е просто начин да живеят в охолство. Пълно е със самозабравили се и самодоволни старци, чиято единствена реална връзка с бога е това, че главите им по цял ден витаят в облаците. Витаят в облаците и не виждат какво става на земята. Ето от къде се пръкна този Николай, тази еманация на всичко псевдо-духовно и не-смирено, който не се опита да даде мир на душите на загиналите, не се опита да успокои близките, а каза „Не, това е божие наказание“. Това е наказание от неговият не-всеупрощаващ и не-милостив бог. „Аз ви предупредих, ама не ме слушате!“

А всъщност колко ли от хората, пострадали или оцелели от трагедията, са били на този небогоугоден концерт? Замислили се изобщо Николай какво се опитва да насади сред черната отрова на това нещастие? Дали пък някой от тези хора не е бил набожен човек, редовно посещавал църквата? Дали дядо Николай, този борец за пречистване на душата на българите, се е допитал до свещениците в Антон за техните енориаши?

Това е поредната неадекватна постъпка на нашата „църква“. Не че няма добри и отдадени на бога духовници, но са по-скоро изключение, колкото по-нагоре в йерархията погледнеш. И това не е от ден или два, няма и да мине за ден или два. Държавата ни може и да се оправи, ама църквата… дай боже. България и българите имат нужда от нашата православна църква. Църква, която да напътства. Да дава надежда, да бъде опора в тежките дни.

Но тази църква я няма.

 Posted by at 8:39
Сеп. 042009
 

Една от малките, но удобни благинки в 11.1 (release one!) е новият синтаксис на ALTER SYSTEM KILL SESSION. Освен стандартните SID и SERIAL, вече има трети, опционален параметър, в който може да се зададе instance id. Това позволява да се прекъсват сесии на „друг“ instance.

Според документацията нещата стоят така:

KILL SESSION Clause

The KILL SESSION clause lets you mark a session as terminated, roll back ongoing transactions, release all session locks, and partially recover session resources. To use this clause, your instance must have the database open. Your session and the session to be terminated must be on the same instance unless you specify integer3.You must identify the session with the following values from the V$SESSION view:

– For integer1, specify the value of the SID column.

– For integer2, specify the value of the SERIAL# column.

– For the optional integer3, specify the ID of the instance where the target session to be killed exists. You can find the instance ID by querying the GV$ tables.

Тук, обаче, не е цялата истина. Ето какво се случва ако следваш документацията:

SQL> select instance_number from v$instance;
 
INSTANCE_NUMBER
---------------
              1
 
SQL> select inst_id, sid, serial#
  2    from gv$session
  3   where username = 'YAVOR'
  4     and program not like '%PZ99%';
 
   INST_ID        SID    SERIAL#
---------- ---------- ----------
         1         12      29935
         1        587       2564
         1       1153       6987
         1       1715       1807
         2        583        494

SQL> alter system kill session '583, 494, 2';
 
alter system kill session '583, 494, 2'

ORA-00026: missing or invalid session ID

Изречението „You can find the instance ID by querying the GV$ tables“ не носи много полезна информация. Тук някой може да си помисли, че описанието на грешка ORA-00026 в същата тази документация ще е полезно. Ето колко е полезно:

ORA-00026: missing or invalid session ID
Cause: Missing or invalid session ID string for ALTER SYSTEM KILL SESSION.
Action: Retry with a valid session ID.

Човек веднага се сеща какъв е проблема, нали 🙂

Чак ме е яд как не ми блесна веднага: следвайки синтаксиса от първите два параметъра (SID и Serial#), съвсем логично е, че третият параметър се задава с @ (кльомба/маймунка). Няма нужда това да се пише в документацията – то е толкова естествено…

SQL> alter system kill session '583,494,@2';
 
alter system kill session '583,494,@2'
 
ORA-00031: session marked for kill
 
SQL> select inst_id, sid, serial#
  2    from gv$session
  3   where username = 'YAVOR'
  4     and program not like '%PZ99%';
 
   INST_ID        SID    SERIAL#
---------- ---------- ----------
         1         12      29935
         1        587       2564
         1       1153       6987
         1       1715       1807

P.S.: И в 11.2 е така

 Posted by at 11:59

Oracle 11.2: любимите ми благинки

 Общи  Коментарите са изключени за Oracle 11.2: любимите ми благинки
Сеп. 022009
 

OCR and Voting disk on ASM
Voting disk-а и Oracle Cluster Registry мгат да се съхраняват на ASM. Това прилича малко на кокошката и яйцето. За целта ASM вече не е част от DB home, а е част от CRS home (наричан вече Grid Infrastructure). С други думи, вече и без клъстерна файлова система няма нужда да цепим малки логически partitions само за OCR и Voting disk. И като сата дума за клъстерни файлови системи…

ASM Cluster File System (ACFS)
Вече ASM има функционалност на Volume manager (то и преди го имаше, но вече малко повече) и на клъстерна файлова система. С други думи ASM придобива функционалността от OCFS, но много с по-голям размах (има дори snapshots). Предстои да уточним до колко ще е успешно.

SCAN адрес
Достъпа до всички нодове в един клъстер вече може да става само през един IP адрес или име. Този адрес е адрес на клъстера, а не на някой нод. В един клъстер може да има един или много SCAN адреси и броят им зависи от нуждите, натоварването или настроението на администраторите, но не и от броя на нодовете. Според мен за голяма част от случаите един scan адрес ще е абсолютно достатъчен и това е голямо улеснение.

Edition-based Redefinition
Невероятна функция, която беше заложена още в 11.1, но не беше пусната. С две думи, възможно е обектите да имат различни версии, които се превключват (примерно при upgrade). Това е голямо улеснение. Предстои да се изглади и като функционалност. Между другото, преди 7 месеца излезе едно много интересно предположение, че някой ден това може да се използва за zero downtime upgrade/patching на самия data dictionary

Flashback Data Archive Support for DDLs
Преди няколко месеца писах за ограниченията, които правят Flashback Data Archive трудно използваем. Вече голяма част от проблемите са отменени: възможни са:
– Add, Drop, Rename, Modify Column
– Drop, Truncate Partition
– Rename, Truncate Table
– Add, Drop, Rename, Modify Constraint
Остава да разрешат и Add partition и вече ще може да се използва съвсем безгрижно

По-интелигентен installer
Ако нещо не се хареса на инсталера, и то може да се оправи с няколко команди (примерно някой параметър на kernel), инсталера генерира скрипт за оправията и предлага на потребителя да го стартира. Освен това инсталера на Grid infrastructure е напълно способен сам да си setup-не SSH conectivity – нещо, което ми тежеше много в старите версии

Deinstall
В ORACLE_HOME/deinstall/ се намира един ужасно полезен скрипт, който прави пълна деинсталация на дадения home. Ужасно полезен, особено за деинсталация на Grid infrastructure.

И още благи неща, които ми харесват:
– ASM configuration assistant (ASMCA) – доста полезен инструмент
– нови екстри в ocrconfig
– Automatic Block Repair при standby database
– IGNORE_ROW_ON_DUPKEY_INDEX Hint for INSERT Statement (нож с две остриета, но все пак е полезно)
– нови и много полезни агрегативни функции: LISTAGG, NTH_VALUE
– Cluster Time Service – синхронизира времето между нодовете в клъстера. Много добра идея. Все пак има и малък кусур: много внимавайте преди инсталация на клъстер времето да е долу-горе синхронизирано, иначе боли
– Columnar Compression – чудеса могат да се направят с новите възможности за компресия (полезни предимно в DWH бази)
– Data Pump Legacy Mode – малко помощ за тези, свикнали със старите imp/exp
– Segment Creation On-Demand – представете си една инсталация на тлъсто приложение с 10000 таблици, които в началото са празни (а някой си остават така завинаги). Всички тези празни таблици и техните индекси вече няма да заемат грам място. Много благо
– Zero-Size Unusable Indexes and Index Partitions – кофти е когато един индекс стане Unusable – но поне вече няма да заема място

Ох, има още много, но всичко по реда си 🙂

Излезе Oracle Database 11g Release 2!

 Общи  Коментарите са изключени за Излезе Oracle Database 11g Release 2!
Сеп. 022009
 

Oracle announces availability of Oracle Database 11g Release 2

Новият release е пълен с благи функцийки, за които с удоволствие ще пиша в следващите дни. Вече всеки може да си го изтегли от OTN

Stay tuned 🙂

 Posted by at 8:08

Пак за преточването на данни

 Общи  Коментарите са изключени за Пак за преточването на данни
Сеп. 012009
 

Като ми следи някой постингите, може да си каже, че само претакам данни насам-натам като зелева чорба. Не е така, рядко се налага, за това пък е хем интересно, хем има достатъчно не-custom, за да мога да го споделям в блога си. А това описание го правя както за споделяне с другите, така и за себе си – след време да не се чудя как го бях направил 🙂

И така, този път ще преточа няколко стотин гигабайта по най-бързия възможен начин: transportable tablespace. Използвам следните уточнения:
– БД-източник е на AIX и е версия 10.2.0.3. БД-приемник е на Linux x64 и е версия 11.1.0.7 (ужасно свежа с пачването, чак до последния CPU), т.е. имаме разлика както във версиите, така и в платформите
– данните в БД-източник са на файлова система, а на БД-приемник ще ги сложа на ASM.
– Имах щастието файловата система на БД-източник да бъде монтирана на сървърите на БД-приемник (read-only), за да мога да си изтакам файловете директно

И понеже има доста tablespaces и ще пренасям данните на порции, гледам да си направя стъпките някак хем прости и малко на брой, хем ефективни. За това си подготвих следните улеснения:
– както вече написах, системните администратори монтираха файловата система с data файловете от системата-източник на сървърите на системата-приемник (read-only!)
– в БД-приемник създадох database link към БД-източник. Напоследък съм много влюбен в използването на Data Pump през databse link (благодаря на Юлиян Дончев, че ми подсказа за това улеснение). По този начин си спестявам генерирането на dump file на едната система и пренасянето му до другата.
– конвертирането на tablespaces става с RMAN. Това е почти единственият начин за прехвърляне на много големи обеми от данни между различни платформи – логическият export/import, бил той по стария начин или с data pump, би отнел ужасно много време. За rman си подготвих скрипт за прехвърляне на данните, за да не набирам всичко всеки път
– прехвърлянето на метаданните, както вече загатнах, извършвам с Data pump. За този етап също си подготвих параметричен файл.

И ето така се достигна до следният сложен механизъм за прехвърляне в 2 стъпки:
1. Конвертиране на файловете от старата платформа към новата, едновременно с прехвърлянето им в ASM. Използвам следният файл:

$ cat ~/rman_convert.cmd


CONVERT DATAFILE '/mnt/oradata/old_db/data/local/big_tbs_01.dbf'
   FROM PLATFORM 'AIX-Based Systems (64-bit)'
   DB_FILE_NAME_CONVERT '/mnt/oradata/old_db/','+DATA/new_db/datafile/';
CONVERT DATAFILE '/mnt/oradata/old_db/data/local/big_tbs_02.dbf'
   FROM PLATFORM 'AIX-Based Systems (64-bit)'
   DB_FILE_NAME_CONVERT '/mnt/oradata/old_db/','+DATA/new_db/datafile/';
CONVERT DATAFILE '/mnt/oradata/old_db/data/local/big_tbs_03.dbf'
   FROM PLATFORM 'AIX-Based Systems (64-bit)'
   DB_FILE_NAME_CONVERT '/mnt/oradata/old_db/','+DATA/new_db/datafile/';
. . .

– За да сработи това трябва съответния tablespace да е read-only на БД-източник през цялото време. Има начини това време да се намали, но за щастие аз мога да си позволя по-дълъг период read-only.
– Както виждате RMAN няма нужда да се закача към БД-източник и не използва контролния и файл, а чете директно посочения datafile.
– Също така тук е интересно, че on-the-fly се случва едно конвертиране от Big endian в Little endian формат на данните.
– Параметърът db_file_name_convert указва как да се промени името на файла (заедно с пътя). По този начин файла се озовава върху ASM
Самото изпълнение се случва така (на новата система):

rman target / cmdfile=~/rman_convert.cmd

2. Прехвърляне на метаданните и „закачане“ на копираните tablespaces в новата БД. Използвам datapump със следния параметричен файл:

$ cat ~/transmore.par
NETWORK_LINK=OLD_DB
TRANSPORT_TABLESPACES=big_tbs_01,big_tbs_02,big_tbs_03, . . .
TRANSPORT_FULL_CHECK=n
TRANSPORT_DATAFILES='+DATA/new_db/datafile/data/local/big_tbs_01.dbf','+DATA/new_db/datafile/data/local/big_tbs_02.dbf','+DATA/new_db/datafile/data/local/big_tbs_03.dbf', . . .
NOLOGFILE=Y
EXCLUDE=STATISTICS

– Важно е пренасяните на един път tablespaces да съдържат всички взаимносвързани обекти – т.е. всички таблици, закачени с foreign keys, всичките им индекси и т.н. Понеже аз знам, че в моя случай съм изпълнил това изискване, инструктирам datapump да не проверява с TRANSPORT_FULL_CHECK=n. Всъщност това си е стойността по подразбиране, но нищо не вреди да я сложа изрично – да се замисля след години като видя същия скрипт
– Параметъра TRANSPORT_DATAFILES указва къде се намират новите файлове. Ако не се зададе това, data pump ще ги търси на същото място, на което са в БД-източник.
– понеже съм си леко мързелив по природа, пък и имам да пренасям десетки tablespaces, си генерирам TRANSPORT_DATAFILES от системата-източник така:

select ''''||replace(file_name, '/mnt/oradata/old_db/', '+DATA/new_db/datafile/')||''',' from dba_data_files; 

Всъщност по аналогичен начин си генерирам и rman скрипта.
Самото извикване на Data pump е

$ impdp system@new_db PARFILE=~/transmore.par

Това е всичко. Само две прости команди… 🙂

 Posted by at 9:02