| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Crystal Reports and the IdiotManager(TM)
> saturated and it was swapping like mad. IdiotManager(TM) had spent most
of
> the last two days in meetings trying to convince executive management that
> it was a "database problem" and that the company should switch to Postgres
> or, preferably, flat files - "for performance". (Seriously! For a 300+
GB
Ah yes! Only too familiar with the species.
> I don't know beans about Crystal (and would actually prefer to keep it
that
> way).
Good decision!
> Does anyone know if it is somehow "tunable" for result sets >>
it does a lot of dynamic SQL and ad-hoc generation of SQL. If you tell
it that you want an aggregation or a header-detail report, it WILL by
default
read ALL rows and do the aggregation itself and/or read ALL headers and
details
and build the report based on that. Before the usual crap reply jumps in:
I said *by DEFAULT*!
This is done to make it supposedly "portable across databases". Which in duhveloper's language means: "we don't know squat about SQL so we just read the data and do all the work ourselves". ..
By teh same token: it won't accept calling a stored procedure. So you can't use the second line of defence, which is to write yourself the SQL and give them just ref cursors. Made darn sure only they could stuff up things...
> memory? Would 2GB of client memory help significantly (at least
> temporarily)?.
If you can get a network that will handle 2Gb transfer rate in usable time, repeatedly, then yes. Don't expect it to run in 10 minutes, though.
> Is this simply a Crystal "scalability ceiling" thing? Does
It can't be: Crystal has got NO scalability whatsoever.
> anyone know of Crystal running well against large (10-500 million records)
> data sets and large (N*million record) result sets?
Unknown to me. We can't even get it to behave on ad-hoc reports with a database that is a minuscule fraction of that size... As for pre-defined reports, if you can do it all n SQL then you're OK, if you need PL/SQL then you're up the proverbial without a paddle.
> duhveloper and mangler. The only way I can think of to make this pig (and
> its cousins) any better is to create materialized views or rollup tables
in
> the database (or better - in another database) and have them change the
> report so that Crystal hits them and doesn't attempt to read millions of
> records to find the "Top 20" of this and that grouped by the other thing.
Yup, sounds good to me. Then wait for further problems, because there are a few more: it's remarkably hard to predict the materialised views needed for ad-hoc reporting...
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision_at_optusnet.com.au
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Sat May 08 2004 - 07:15:04 CDT
 |
 |