It’s always a pain to remember the exact number of ticks needed to get the quoted output.

Here is a reminder on how to do it:

select ''''||schemaname||'.'||tablename||'''' from pg_tables

4 quotes when there’s no text, or 3 quotes on the outside and one on the inside when there is text.

select '''public.'||tablename||'''' from pg_tables

I recently ran into a problem like that in PostgreSQL, the query ran fine *most* of the time, but every once in a while it would go off into the weeds.

After a little digging I realized that the table’s statistics hadn’t been updated in quite a while. This struck me as odd since I knew that PostgreSQL automatically updates statistics on a regular basis. So I did some digging to figure out exactly what triggers statistics to be updated in PostgreSQL.

First off, it’s important to note that in postgresql the vacuum process is what handles statistics. “vacuum analyze” is the command although you can just use “analyze” too. Vacuuming and analyzing are different operations, and have different, but very similar parameters that control them.

The key postgresql.conf parameters that affect whether or not a table gets auto-analyzed are:

#autovacuum_analyze_threshold = 50
#autovacuum_analyze_scale_factor = 0.1

(You can see the defaults in the postgresql.conf above)

The formula that Postgres uses to determine if a table needs to be auto-analyzed is
([ # of rows in table ] * [ scale factor ]) + [ threshold ]

So, for example, if you have a table with 10,000 rows in it, then it would look like this:
( 10000 * 0.1 ) + 50 = 1050

So if you were to add 1049 rows, the table would not get auto-analyzed.

So how do you change it? Well, there are 2 ways. you could change the 2 parameters in the postgresql.conf, and this is a good idea if you think you need to globally lower or raise them.
However, I think in most cases you’ll want to make the change just for one table, which means you need to utilize the pg_autovacuum table.

postgres=# \d pg_autovacuum
    Table "pg_catalog.pg_autovacuum"
      Column      |  Type   | Modifiers
------------------+---------+-----------
 vacrelid         | oid     | not null
 enabled          | boolean | not null
 vac_base_thresh  | integer | not null
 vac_scale_factor | real    | not null
 anl_base_thresh  | integer | not null
 anl_scale_factor | real    | not null
 vac_cost_delay   | integer | not null
 vac_cost_limit   | integer | not null
 freeze_min_age   | integer | not null
 freeze_max_age   | integer | not null
Indexes:
    "pg_autovacuum_vacrelid_index" UNIQUE, btree (vacrelid)

Remember when I mentioned above that vacuuming and analyzing were handled via similar mechanisms? you can see that here, the table has fields related to vacuuming and analyzing.

The fields we care about for this particular problem are: vacrelid, enabled, anl_base_thresh and anl_scale_factor.

• vacrelid is the OID of your table. you can get that via:

select oid from pg_class where relname = [tablename]

• enabled is “true”
• anl_base_thresh is your new autovacuum_analyze_threshold
• anl_scale_factor is your new autovacuum_scale_factor

To make the parameter change for just one table we then need to insert into the pg_autovacuum table.

postgres@postgres=# select oid from pg_class where relname = 'test_vac';
   oid
---------
 1579952

postgres@postgres=# insert into pg_autovacuum(1579952,true,50,0.2,50,0.09,20,-1,100000000,200000000)

I’m changing the scale factor from 0.1 to 0.9, the rest are the default values for those parameters
What that means is in our example:
( 10000 * 0.1 ) + 50 = 1050
Changes to:
( 10000 * 0.09 ) + 50 = 950

In other words, the autovacuum would kick off 100 records sooner, not a huge difference, I know however to the planner it could make all of the difference in the world.

The reason I wanted to use HA-JDBC is that I was looking for a no-coding required solution for seamless fail over. (Similar to Oracle RAC) for PostgreSQL.

I’ll be using a Shared Disk / Heartbeat cluster on the server side, however when the node fails the application will register an error, which is undesirable.

After doing more research it’s been determined that HA-JDBC won’t work.

It seems that HA-JDBC is, at best, a SQL replicator, where you have 2 active nodes and HA-JDBC will perform inserts and updates across both databases to keep them in sync. This is fine if you’re not using the “serial” data type in PostgreSQL, Triggers, Functions, time based default values, etc. Using any sort of trigger, the code fires independently on insert and you end up getting out of sync databases.

Another reason why HA-JDBC won’t work is that if a node is un-reachable HA-JDBC removes it from consideration. So your 2nd “standby” when it becomes active won’t be considered by HA-JDBC without some manual intervention.

And finally, I’d advise steering away from HA-JDBC at this point even if the above works for you. I posted a few clarifying questions regarding the above to both the HA-JDBC forums and their mailing list and received no response. If your business is looking into true high availability for their servers you need to choose all of your components with care. A non-responsive community either means the project is dead, or un-caring, both of which are unacceptable when you’re looking into HA solutions.

Finally got a response from Paul Ferraro, Nice guy, very helpful posted below:

Sorry for the slow response...

HA-JDBC is not the right tool for this job.  HA-JDBC is an
*alternative* to shared disk failover - it was not designed
to be used in concert with it.  Instead, you want something
like JBoss HA DataSource or Weblogic multi-pools.  These are
DataSource proxies whose getConnection() method returns a
raw connection from the first available data source.
DataSource-level.  Connections returned by HA-JDBC's DataSource,
on the other hand, are proxies to connections to each active
database in your cluster.

I can go into more detail if you'd like, such as the advantages/
disadvantages of HA-JDBC over shared-disk failover, if you're
interested.

Paul

I’m doing a trace on a very long running ETL process and the logfile generated is ~11GB.

I’m running up against a 2GB barrier in php for fopen(). If you’ve got a 64bit machine and can recompile php with -D_FILE_OFFSET_BITS=64 then you’re good to go. But in my case, I can’t do either.

The error i’d get is:

PHP Fatal error:  File  is not readable. in /var/lib/pgsql/pgfouine-1.1/include/GenericLogReader.class.php on line 85

So for Plan B I had to remember back to the days when 64 bit wasn’t even an option (back in my day, we had 8 bits and we liked ‘em!)

I used a named pipe since pgfouine expects a file and doesn’t seem to be able to read from stdin.

mknod /tmp/pg2 p
cat /var/log/postgres > /tmp/pg2 | ./pgfouine.php -file /tmp/pg2 > bla.html

Once that kicked off I stopped getting that error and pgfouine was able to process the file.

Without updating the JDBC driver you would have to catch the failure at the java container level or in the app itself and manage the switch from the down node to the active node.
I don’t think that’s “industry standard” and it’s certainly not easy by any means.
The normal way is to let the JDBC driver manage it.

Unfortunately the PostgreSQL JDBC driver doesn’t handle this event out of the box so we need to invoke a 3rd party.

There aren’t a lot of options in this area here are two:

• HA-JDBC
• Tungsten SQL Router which used to be called Sequoia

I found a good discussion around HA-JDBC here

I’m using Hibernate + Geronimo so i need to do testing to see if that’s going to work with HA-JDBC but from the sounds of it, it should work just fine.

I’ll need to evaluate both of these to determine which is the best.

The reason I’m looking at clustering is that the DB server will be handling a large number of users and any downtime is catastrophic. So reliability comes before any performance or administrative concerns in a clustering solution.

My platform is PostgreSQL 8.3 and SLES Linux.

I looked at 4 Solutions:
Option 1: Shared Disk (Heartbeat) Cluster (Heartbeat: SLES)
Option 2: Filesystem Replication Based (DR:BD / GNDB)
Option 3: DB Replication Based (Slony I)
Option 4: DB Replication Based (PGCluster)

I weighed the pro’s and con’s of each of them and eventually chose Option 1 as the best for my needs.

I like the heartbeat solution because:

• It’s simple
• There’s no data loss in a shared disk cluster
• There’s no replication overhead so no performance impact

Unfortunately, there is very little public documentation regarding heartbeat clusters used with PostgreSQL. I hope to rectify that over the next weeks and months, so stay tuned.

DBSLOG to help find out what’s going on when a session “hangs”

I’ve placed a lock on a record in the item master. The bottom of the dbs.log looks like this:

------ QPS Input Row -------
Bind :1   : string  : [0x8185d20] '`               '
----- DBMS Where Input ----
Bind nr 1 : item       : string  : '`               '
SQL> ora_multi_execute( 0x81cb0d8 ) do 0, prefetch 1

There is a lot of information in these few lines.
First: Bind nr 1 : item : string : ‘` ‘
is the binding of “item” to the string “` ” which is a dummy item in my database.

Second: SQL> ora_multi_execute( 0x81cb0d8 ) do 0, prefetch 1
Tells us the hex value for the cursor further up in the dbs.log file that we’re executing.

Now to find out the query that’s locked we just use that hex value 0x81cb0d8 and search backwards in the file:

SQL> ora_parse( "SELECT /*+  index(a ttiitm001200$idx1) */ t$item,t$dsca,t$dscb,t$dscc,t$dscd,t$wght,t$seak,
t$seab,t$kitm,t$citg,t$ctyp,t$csel,t$csig,t$cvat,t$txta,t$uset,t$cuni,t$stgu,t$cwar,t$kltc,t$obpr,t$kpsl,t$npsl,t$pics,
t$abcc,t$lcod,t$uscu,t$usab,t$slmp,t$serv,t$sfst,t$maxs,t$csps,t$cspd,t$cfmd,t$scst,t$stoc,t$blck,t$ordr,t$allo,
t$hall,t$quot,t$ltdt,t$opol,t$osys,t$omth,t$oqmf,t$mioq,t$maoq,t$umer,t$fioq,t$ecoq,t$reop,t$oint,t$ddfq,t$oltm,
t$sftm,t$fodt,t$ocst,t$auso,t$cpha,t$oqdr,t$repi,t$scdl,t$orip,t$pcrp,t$stpm,t$mrpc,t$plmm,t$mrpo,t$eitm,t$bfcp,
t$bfep,t$bfhr,t$ndrp,t$nnts,t$qpnt,t$unom,t$runi,t$scpf,t$crmp,t$tmfc,t$roun,t$ncst,t$llcd,t$llci,t$mrpi,t$stmr,
t$cuqp,t$cupp,t$cpgp,t$csgp,t$pcgp,t$ccur,t$ltpp,t$prip,t$avpr,t$ltpr,t$suno,t$qual,t$purc,t$txtp,t$cuqs,t$cups,
t$cpgs,t$csgs,t$cmgp,t$rbgp,t$pris,t$ltsp,t$prir,t$umsp,t$lmsp,t$ccde,t$ctyo,t$txts,t$cpcp,t$copr,t$matc,t$oprc,
t$cuid,t$actf,t$ltcp,t$stva,t$buyr,t$cplb,t$cppp,t$ccit,t$ccfu,t$ccco,t$prre,t$copt,t$cprp,t$itmt,t$proi,t$cont,t$cntr,
t$czed,t$reli,t$assi,t$potc,t$ffsi,t$qbsi,t$osyc,t$ufra,t$nobd,t$blcm,t$dcnt,t$exkb,t$itm2,t$Refcntd,t$Refcntu
FROM baan.ttiitm001200 WHERE t$item=:1 FOR UPDATE WAIT 9000 " )
SQL> ora_parse( 0x81cb0d8 )

You see the ora_parse (0x81cb0d8) which matches up with the ora_multi_execute

So you know that in this particular case, the session is “hanging” because it cannot acquire a lock on ttiitm001200.

You use the same process to identify slow queries, wrong queries, etc.

<6692> 2009-11-09[20:17:44]: Logging started mode 01570
        ---- LOG ROW   INFO [0000010] ----
        ---- LOG TABLE INFO [0000020] ----
        ---- LOG DB    INFO [0000040] ----
        ---- LOG DBMS  INFO [0000100] ----
        ---- LOG SQL   INFO [0000400] ----
        ---- LOG DEBUG INFO [0001000] ----

This next part is more valueable than you might think. These are the parameters that your bshell/driver are picking up. This is a great place to look if you’ve set a parameter in your db_resource or tabledef and it doesn’t appear to be getting used.

It’s also a great way to find hidden tuning parameters ;)

Portingset mode 6.1c

oracle_attach_server
Timeout values : [9000] [900] [900] [900] [900]
allocate_sql_buffer_area size 32000.
oracle client version = 10.2.0.4.0
oracle_attach_server done.
Resources:      (E = env, P = putenv, D = default )
    lock_retry                E     "0"
    locale                      D   ""
    bdb_max_session_schedule  E D   -1
    bdb_max_sessions          E D   -1
    rds_full                  E     5
    tt_sql_trace              E D   037777777777 (oct)
    dbslog                    E     01570 (oct)
    dbslog_name               E D   "dbs.log"
    dbsinit                   E     021 (oct)
    baan_single_shot_queries  E D   0
    max_tables_joined         E D   -1
    cs_owner                    D   0 (oct)
    enable_refmsg             E D   0
    use_binary_columns        E D   0
    hint_idx_weight_equal     E D   1
    hint_idx_weight_range     E D   1
    hint_idx_weight_factor    E D   < 1.00000000>
    tbase_refresh               D   -1
    concat_expr               E D   ""
    aud_init                  E D   0
    audit_mask                E D   0 (oct)
    baan_sql_trace            E D   0 (oct)
    baan_sql_cacherows        E D   -1
    nls_lang                  EP    "american_america.we8iso8859p1"
    nls_sort                  EPD   ""
    oracle_home               EP    "/apps/oracle/10gR2"
    oracle_service_name       E D   ""
    oracle_sid                EP    "BAANTEST"
    two_task                  E D   ""
    oracle_client_home        E D   "/apps/oracle/10gR2"
    oracle_server_home        E D   "/apps/oracle/10gR2"
    oracle_local_template     E D   ""
    ora_sqlnet_compression    E D   1
    epc_disabled              EPD   "TRUE"
    ora_max_array_fetch       E     5
    ora_max_array_insert      E     5
    baan_oracle_prefetch      E D   1
    ansi_outer_join           E D   0
    use_oci7_interface        E D   0
    max_free_cursors          E D   32
    retained_cursors          E D   50
    max_sql_buffer            E D   32000
    sql_trace                 E D   ""
    ora_timeout               E     "{9000,900,900,900,900}"
    optimizer_goal            E D   ""
    ora_alter_session         E D   ""
    ora_default_tablespace    E     "baandata"
    ora_temporary_tablespace  E     "temp"
    ora_init                  E     0101000 (oct)
    ora_level1                E D   0
    max_open_cursors          E D   245
    ora_date                  E D   0
    oraprof                   E D   < -1.00000000>
    oraprof_name              E D   "oraprof"
    orastat                   E D   < -1.00000000>
    orastat_name              E D   "orastat"

Next it starts the connection to the database process. I’ll simulate an error 510 (database not on) so you can see where you can see where it would go wrong in the connection.
Here you see the error 510, the resulting oracle errors

Error ORA-1034 occurred during logon.
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory

and the info you need to find the problem:

ORACLE_SID=bla

Naturally, my database SID isn’t “bla”

Here’s the full trace:

Msg_type 13 received.
Msg_type 2 received.
oracle_open_session sid 1.
Open session : logon
ora_logon : name = 'bsp', pwd = .. ora_session 0x816f588
using resource oracle_local_template
oci_link_server ( dbase = '(DESCRIPTION=(SDU=8192)(TDU=8192)(ADDRESS=(PROTOCOL=beq)(PROGRAM=/apps/oracle/10gR2/bin/oracle)(ARGV0=oraclebla)(ARGS='(DESCRIPTION=(LOCAL=YES)(SDU=8192)(TDU=8192)(ADDRESS=(PROTOCOL=beq)))')(ENVS='ORACLE_HOME=/apps/oracle/10gR2,ORACLE_SID=bla'))(CONNECT_DATA=(SID=bla)))' ) : first time linked : attach connection : # logon = 1 : OK
ora_logon : OCISvcCtx  0x81b2a78 Allocated
oracle server version = 10.2.0.4.0

ora_error 1034 dbs_errno 510.
oci_unlink_server ( dbase = '(DESCRIPTION=(SDU=8192)(TDU=8192)(ADDRESS=(PROTOCOL=beq)(PROGRAM=/apps/oracle/10gR2/bin/oracle)(ARGV0=oraclebla)(ARGS='(DESCRIPTION=(LOCAL=YES)(SDU=8192)(TDU=8192)(ADDRESS=(PROTOCOL=beq)))')(ENVS='ORACLE_HOME=/apps/oracle/10gR2,ORACLE_SID=bla'))(CONNECT_DATA=(SID=bla)))', # logon = 1 ) : detach connection : OK
ora_logon error: ora_session 0x816f588 err 510
FATAL /view/port.6.1c.07.08/vobs/tt/servers/ORACLE_2/ora_native.c:#1769 :

Error ORA-1034 occurred during logon.
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory

Error BDB-510 returned.
Check the Oracle settings:
NLS_LANG = 'american_america.we8iso8859p1'
ORACLE_HOME (client) = '/apps/oracle/10gR2' (resource oracle_client_home)
ORACLE_HOME (server) = '/apps/oracle/10gR2' (resource oracle_server_home)
Oracle Service Name = '' (resource oracle_service_name --> TWO_TASK)
ORACLE_SID = 'bla'
Connection used oracle_local_template ( ? = oracle_server_home, @ = oracle_sid ):
(DESCRIPTION=(SDU=8192)(TDU=8192)(ADDRESS=(PROTOCOL=beq)(PROGRAM=/apps/oracle/10gR2/bin/oracle)(ARGV0=oraclebla)(ARGS='(DESCRIPTION=(LOCAL=YES)(SDU=8192)(TDU=8192)(ADDRESS=(PROTOCOL=beq)))')(ENVS='ORACLE_HOME=/apps/oracle/10gR2,ORACLE_SID=bla'))(CONNECT_DATA=(SID=bla)))

Logon failed; errno 510
Msg_type 1 received.
In detach server
oracle_detach_server
oracle_detach_server done.
In detach server

I’m mostly familiar with the Oracle driver, so that’s what i’ll show here. Other drivers look different in DBSLOG.

Here are the options that can be sent to DBSLOG:

00000 – Turn DBSLOG tracing off
00001 -  Display data dictionary information on queried tables
00002 -  Display Query information for level one database queries
00004 -  Display query execution plan during a level two query
00010 -  Row level action (read, modify, delete) information
00020 -  Table level action information
00040 -  Translation information
00100 -  DBMS input/output data on a level two query
00200 -  Administrative file information for SQL drivers
00400 – DBMS SQL query statements
01000 -  General debug statements
02000 – Query processing information
04000 – Data buffering information passed thru communication channels

Basically you add the values to get the level of debugging level you want.

You might think that setting DBSLOG=99999 would give you everything you need, but that’s not always true. Some flags are mutually exlusive, and some flags add so much information as to make the file unreadable.

That’s why I always use DBSLOG=01570 which gives you:

General debug statements (1000) +
DBMS SQL query statements (400) +
DBMS input/output data on a level two query (100) +
Translation information (40) +
Table level action information (20) +
Row level action (read, modify, delete) information (10)

Unlike the bshell debugging commands DBSLOG is set via the environment so you would use

Unix:
export DBSLOG=01570
Windows
set DBSLOG=1570
Baan:
-- -set DBSLOG=1570

The logfile will be called dbs.log and will be located in your home directory in unix or $BSE/tmp in windows.

Before we saw that the object for my item master oitm0101 was located here:

/apps/baan/bse/application/tiB40U_c4_stnd/otiitm/oitm0101

Now if we want some info we can use one of three commands

what /apps/baan/bse/application/tiB40U_c4_stnd/otiitm/oitm0101
- or (if you're fancy) -
what `explode6.1 otiitm0101`
- or -
bic_info6.1 -w oitm0101

You can use bic_info.exe for Windows.

Both will give the result below:

---------------------------OBJECT IDENTS--------------------------------
@(#)/b40c/bse/application/tiB40_c5/ptiitm/pitm0101g, 04/11/16 [20:34], From wtreur
@(#)-DREL6_1
@(#)4GLE_BUILD_BaanIVc7_1184 -- bic_global@@/main/bugfixB40c6/developmentB40c7/10
@(#)4GLE_BUILD_BaanIVc7_1184 -- bic_object@@/main/bugfixB40c6/developmentB40c7/2
@(#)4GLE_BUILD_BaanIVc7_1184 -- bic_event@@/main/bugfixB40c6/developmentB40c7/1
[....]

Here you can see the compile date of the object, this is critical with dealing with Baan support
as they can usually map that object info to a defect or solution number assuming it’s a standard object.