Re: What information to gather

From: Toon Koppelaars <>
Date: Wed, 1 Jul 2009 19:53:02 +0200
Message-ID: <>

> , if a bit slow

WHAT? I contend that an Apex approach to displaying some data out of the database into a browser, performs an order of magnitude faster, than having to pull the data through 42 tiers...


On Wed, Jul 1, 2009 at 7:12 PM, Guillermo Alan Bort <>wrote:

> I know this *might* be a bit of a repeated thread. However... here I go.
> Due to reasons to boring to get into, the company I work for is not going
> to invest in a monitoring tool. However, we have a few DBs that work only as
> RMAN catalogs. Servers are oversized so we can build new DBs there. I wanted
> to have a central repository of information for our databases... so I was
> wondering what information to take.
> What I have so far:
> =============
> DB Name
> Parameters (v$parameters)
> archive deestination
> backup status (last backup and all backup drilldown).
> Performance information (I'm still working on this, either statspack or awr
> reports/snapshots)
> Space management (tablespaces, datafiles, autoextend, extent management,
> segment space management, size, free space, etc)
> User management (users, account status, etc)
> There will be no real time information, so hang analysis and such will not
> be possible, plus information from v$ views won't be that useful.
> The idea with this is that the data will be updated in the central DB and
> it will be accessed via a APEX application I'm developing (thank god for
> APEX... I am a fairly good PL/SQL developer but simply refuse to write java,
> so APEX gives a good alternative, if a bit slow)
> thanks in advance.
> Alan Bort
> Oracle Certified Professional

Toon Koppelaars
RuleGen BV

(co)Author: "Applied Mathematics for Database Professionals"

Received on Wed Jul 01 2009 - 12:53:02 CDT

Original text of this message