No question at this time
DBA Top 10
1 M. Cadot 6500
2 B. Vroman 2700
3 J. PĂ©ran 1600
4 P. Tsongayinwe 1500
5 P. Wisse 1200
6 A. Kavsek 1100
7 D. Walgude 400
7 J. Schnackenberg 400
9 J. Alcroft 200
10 A. Hudspith 100
10 D. Johnson 100
10 B. B 100
The DBA-Village forum
Forum as RSS
as RSS feed
Site Statistics
Ever registered users48695
Total active users1323
Act. users last 24h3
Act. users last hour0
Registered user hits last week79
Registered user hits last month345
Comment details
Date 14-NOV-05
Type Comment
User Geert De Paep
Message Replies to some of the remarks given so far:

About the CPU usage, indeed, there is a lot of string processing involved in printing the output. The package however is intended to be run sporadically, or can be scheduled e.g. weekly during low activity. It has grown from something small to something advanced, and the focus has always been on functionality because that is its biggest value. Also for a long time it used no tables, it was just pure plsql. As a consequence a lot is done in plsql tables, causing relatively much cpu. I've already used plsql_profiler on it, but cpu is not concentrated in one particular piece of code.

About the MV error, should be gone in the next version. The code where this error is caused is completely rewritten. There may be other bugs in it, I know, please report them, but I try to make sure that only parts of the output fail in that case, and not the complete package with no output at all.

Datafiles (and related info) are omitted if there are too many, because I have one database with +900 files, causing the plsql output buffer to overflow in html output (+1Mb). Plans exist to introduce customizable parameters. Will be for some day in the future.

It is wrapped, not to hide something, but to protect the source code. Maybe one day this will become an open source project, but for the moment that is not the case.