HDR photos in Lightroom

Trying Easy HDR software as an Lightroom plugin - http://www.easyhdr.com/lightroom.php
Helped author to test this plugin a bit and got a earned a license :)
Have to teach myself about tone mapping now - merged HDR result has a somewhat "too vivid" colors... :)

Python 2.7 on RHEL 6.3

RHEL 6.3 comes with python 2.6 and there are some utilities like yum that depends on it. I wanted to use 2.7 at the same time, so decided to compile it from source and maintain two Python versions in the system.

The new one will be installed into /opt/python2.7

Steps:

0. Install some of the libraries/header files that python may need.
yum install libffi-devel.x86_64
yum install valgrind.x86_64 valgrind-devel.x86_64
yum install expat-devel.x86_64
yum install sqlite-devel.x86_64
yum install gdbm-devel.x86_64
yum install readline-devel.x86_64
yum install bzip2-devel.x86_64
You may decrease this list, depending on what python modules or functionality you plan to use.

1. Determine how system's python was compiled - run
import distutils.sysconfig
print distutils.sysconfig.get_config_vars('CONFIG_ARGS')

using python that comes with OS. So now using this output from python script you'll come up with a configure parameters,
for example:

2. cat myPyConfigure.sh
export CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector \
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv"
export CPPFLAGS="-I/usr/lib64/libffi-3.0.5/include"

mkdir -p /opt/python2.7/share

./configure \
--prefix=/opt/python2.7 --exec-prefix=/opt/python2.7 --datadir=/opt/python2.7/share \
--includedir=/usr/include \
--enable-unicode=ucs4 --enable-shared --with-system-ffi --with-system-expat --with-valgrind

3. Run configure, and then make
You will receive a warning like
Python build finished, but the necessary bits to build these modules were not found:
_bsddb _tkinter bsddb185
dl imageop sunaudiodev

Again, some of these modules you may not need, and some are deprecated. "_bsddb" is Berkley DB that can be downloaded from Oracle. "_tkinter" is TCL/TK - if you plan to use it, then you need to install two more modules using yum.

4. make install

5. Add /opt/python2.7/bin to PATH.

6. echo "/opt/python2.7/lib" >> /etc/ld.so.conf
ldconfig
ldconfig -v | grep python2.7
Make sure that last command returns a path of the Python 2.7 shared library.

That's it.

move indexes into appripriate schemas

Can anybody tell me what's the point of having indexes in a schema other than table's schema? I couldn't tell why this maybe needed, but can tell a few disadvantages of this. Found some of these indexes in one of the databases we have and here's a query that generates DDLs to fix this:

select i.owner,i.index_name, i.table_owner,i.table_name
     , 'DROP INDEX '||i.owner||'.'||i.index_name||';'||chr(13)||
       to_char(regexp_replace(dbms_metadata.get_ddl('INDEX', i.index_name, i.owner)
              , 'CREATE INDEX "'||i.owner||'"', 'CREATE INDEX "'||i.table_owner||'"')
                        )||';' as ddl                        
from dba_indexes i
where owner<>table_owner
order by owner,table_owner
;

kill long-running transactions

I've scheduled the following procedure to kill sessions with long-running transactions in one of the development databases.

CREATE OR REPLACE PROCEDURE SYSTEM.kill_long_transactions AS
        c_maxhours         CONSTANT number := 3.9; 
        l_sql              varchar2(400);  
        e_nosession        exception;
        pragma exception_init(e_nosession, -30);
BEGIN
        FOR rec IN (SELECT 'ALTER SYSTEM KILL SESSION '''||vs.sid||','||vs.serial#||''' IMMEDIATE' killsessionsql
                    FROM v$transaction vt, v$session vs 
                    WHERE vt.addr = vs.taddr 
                      AND (SYSDATE - TO_DATE(vt.start_time,'MM/DD/YY HH24:MI:SS'))*24 >= c_maxhours
            ) 
        LOOP
        BEGIN
                execute immediate rec.killsessionsql;
                -- dbms_output.put_line(rec.killsessionsql);
        EXCEPTION WHEN e_nosession THEN NULL;
        END;
        END LOOP;
END;
/

There are some concerns for long-running transactions eg. in case of Golden Gate replication (it replicates only committed changes and holds in memory transaction states that aren't committed yet). So this scheduled proc can help in case if developers forgot to hit commit/rollback and go out to vacation :-)

restore dropped package using log miner

Log Miner isn't supposed to be used for DDL recoveries, but can be used in some cases.
For example, you can restore a dropped package.
The trick is that source is stored in SYS.SOURCE$ table - so you can see a DROP PACKAGE [BODY] DDL in LogMiner as a set of DELETEs on SYS.SOURCE$ table.

1. Step first - start LogMiner session pointing to necessary online/archived log files. You can check Oracle docs how to do this - eg. http://docs.oracle.com/cd/B19306_01/server.102/b14215/logminer.htm#i1006391

2. Now we can mine logs through the V$LOGMNR_CONTENTS view.
Let's create a temp table with data that we'll analyze to simplify our future queries and make them run faster (otherwise every time you query V$LOGMNR_CONTENTS Oracle actually fetches data from logs):

CREATE TABLE TMP_RESTORE_PACKAGE_LOGMNR
TABLESPACE <staging_nologging>
AS SELECT * FROM V$LOGMNR_CONTENTS
where seg_owner='SYS' AND seg_name='SOURCE$'
  and operation='DELETE';

3. Let's find out what is the OBJECT_ID of that dropped package:

SELECT TIMESTAMP, SQL_REDO, SQL_UNDO
FROM TMP_RESTORE_PACKAGE_LOGMNR
where upper(sql_redo) like '%YOUR_PACKAGE_NAME%'

find out an interesting lines in the SQL_UNDO column with package body source you're interested in and write down a string like "OBJ#" = '62431' in the SQL_REDO - where 62431 can be any positive integer (object_id of the dropped package).

4. Finally, let's recover package body:

SELECT TIMESTAMP, SQL_UNDO
FROM TMP_RESTORE_PACKAGE_LOGMNR
where SQL_REDO LIKE '%"OBJ#" = ''62431''%';

Every line in SYS.SOURCE$ is a separate line in your package/package body. So you need to fetch multiple line and merge contents of SQL_UNDO later manually. You also may fetch multiple instances of that package if it was dropped and recreated multiple times that day - use TIMESTAMP to spot version you find useful.

ps. Of course, SVN/CVS etc is a must and don't rely on this technique too much...

golden gate staging tables

It makes sense not to replicate staging tables. Here's a trick to catch tables that got truncated frequently and are likely staging...

grep TRUNCATE *log |grep "DDL operation included" \
| perl -nle '$h{"$F[-4].$F[-2]"}++; 
END{foreach(sort keys %h){print "$_:$h{$_}"}}' \
  -a -F'/\[|\]/'

After reviewing this list and confirming that those are really staging tables that shouldn't be replicated (because end results of processed staging tables are in the "permanent" tables that are being replicated).

HTH

Oracle memory usage on AIX

Should be calculated as RSS - TRS. See details on ML Note 123754.1

Here's a more convenient command to use:

ps -ef | grep ora | awk '{print $2}' | xargs -n 1 ps vw \
        | awk '{print $7-$10,$0;priv+=$7-$10;trs[$9]=$10} \
END{for(tsiz in trs){TRS+=trs[tsiz]}; print priv+TRS," :TOTAL (",priv,"private memory,",TRS,"shared code segments - TRS)"}' \
        | sed '1p;/^0/d' | sort -n +0

(can be on 1 line obviously).

Prints original ps vw header and list of processes sorted by (private) memory consumption, totals.

The trick here is that we should calculate shared(code segments) only once.
As ML Note mentioned above says, "To get a good estimate of memory usage for all oracle background processes, sum the private memory for each background process plus the value of TRS for only one of the background processes, plus the size of the SGA."

The command above gives information regarding all "ora" processes, not just spawned from $ORACLE_HOME/bin/oracle binary image. So I used TSIZ column to understand if it's the same image or not. The value of TRS will be "approximately" the same for all oracle background processes. I took just one TRS size per every occurrence of TSIZ value - see trs[tsiz] hash above.

Notes:
1. The more accurate values for private/shared breakdown you can probably get going through svmon -P output, but this will be trickier.
2. You can use ipcs -bm to get SGA segments sizes.

HTH.