Hallo,
ich möchte gerne wissen, welche Tabellen dem Datenbankuser TAIM zugeordnet sind, und wieviele Einträge die haben.
Den ersten Teil bekomme ich ja noch hin:
select table_name from all_tables where all_tables.OWNER = ‚TAIM‘
so nun möchte ich gerne wissen, wieviele Einträge die einzelnen Tabellen haben und das ganze natürlich in einer Abfrage.
Weiß jemand wie das geht?
Gruss
Sina
Hallo Sina,
SELECT table_name ,num_rows FROM
sys.dba_all_tables WHERE owner = ‚TAIM‘;
Gruss
Ilona
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
grade mal gewerkelt…
ist zwar wahrscheinlich durch die linke brust ins auge aber funktioniert…
spool C:\temp\daten.sql
select ‚select count(*) from ‚|| table_name ||‘;‘ from user_tables;
spool off
set echo on
spool C:\temp\ergebnis.sql
@C:\temp\daten.sql
echo off
spool off
Hey super danke,
nun hab ich sogar das Prinzip
begriffen so Kram irgendwo in ne
Datei umzuleiten.
Echt klasse.
Sina
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
etwas off-topic
hallo sina
offenbar verwendest du oracle. unter oracle sollte man regelmässig die statistiken für die einzelnen tabellen neu berechnen, da sonst der cost-based-optimizer schrott liefern KANN. folge: zugriffe werden teilweise schlagartig langsamer.
die alte methode um die statistik zu berechnen wäre:
analyze table [compute|estimate] statitistics ;
compute berechnet die ergebnisse genau, ist damit auch ziemlich langsam. estimate schätzt die ergebnisse aufgrund ca. 10 % der daten, ist damit hinreichend genau und viel schneller.
angenehmer nebeneffekt: in der user_tables steht dann die anzahl der zeilen im feld „num_rows“. die abfrage reduziert sich damit auf:
select table_name, num_rows from tabs ;
aber wie gesagt, geht nur mit aktuellen statistiken. sofern du nicht auf datensatz genau die ergebnisse benötigst, ist das aber auf jeden fall eine sinnvolle alternative (und vielleicht wird deine applikation dadurch sogar schneller).
es gibt auch eine „neue“ variante, die statistiken zu berechnen (läuft seit oracle 8 über system-prozeduren). dafür solltest du aber den enterprise-manager verwenden, sonst wird das ganze mühsam. die alte variante funkioniert aber nach wie vor (auch mit aktueller oracle-version).
erwin
hi!
da sonst der cost-based-optimizer schrott liefern
KANN. folge: zugriffe werden teilweise schlagartig langsamer.
außer es befindet sich ein RULE oder USE INDEX oä irgendwo … aber auch nach dem erstellen der statistiken war CHOOSE leider sehr oft nicht viel perfomanter
die alte variante funkioniert aber nach wie
vor (auch mit aktueller oracle-version).
10g? ich dachte, diese version macht schon alles selber 
grüße,
tomh
hi!
10g? ich dachte, diese version macht schon alles selber
Natürlich, ist ja auch die erste Oracle-Version die g eht *lol*
Im Ernst: Wenn ich die bei der letzten Veranstaltung zum Thema richtig interpretiere, dann habe die den RBO ebenso wie die hints mehr oder weniger abgedreht (zumindest prüfen sie mittlerweile, ob denn der CBO zum gleichen Ergebnis kommt, wie der execution plan, der mit RBO/hints rauskommt).
Gruß,
Martin *derimherbstwiederdrachensteigengeht*
Hallo Erwin!
es gibt auch eine „neue“ variante, die statistiken zu
berechnen (läuft seit oracle 8 über system-prozeduren). dafür
solltest du aber den enterprise-manager verwenden, sonst wird
das ganze mühsam. die alte variante funkioniert aber nach wie
vor (auch mit aktueller oracle-version).
1.) Oracle weist ausdrücklich darauf hin, dass man den ANALYZE nicht mehr verwenden soll, ausser man benötigt Ergebnisse, die von DBMS_STATS (das ist die neue Variante) nicht liefert (freelist blocks, validate/list chained rows).
2.) Was ist an der neuen Variante so mühsam?
DBMS_STATS.GATHER_DATABASE_STATS (
estimate_percent NUMBER DEFAULT NULL,
block_sample BOOLEAN DEFAULT FALSE,
method_opt VARCHAR2 DEFAULT ‚FOR ALL COLUMNS SIZE 1‘,
degree NUMBER DEFAULT NULL,
granularity VARCHAR2 DEFAULT ‚DEFAULT‘,
cascade BOOLEAN DEFAULT FALSE,
stattab VARCHAR2 DEFAULT NULL,
statid VARCHAR2 DEFAULT NULL,
options VARCHAR2 DEFAULT ‚GATHER‘,
statown VARCHAR2 DEFAULT NULL,
gather_sys BOOLEAN DEFAULT FALSE,
no_invalidate BOOLEAN DEFAULT FALSE,
gather_temp BOOLEAN DEFAULT FALSE);
Wenn man cascade noch auf TRUE setzt, dann macht das Ding mA alles richtig. Natürlich kann man sich mit den Parametern noch ein wenig spielen, aber im Großen und Ganzen war’s das schon…
Gruß,
Martin
hi!
Im Ernst: Wenn ich die bei der letzten Veranstaltung zum Thema
richtig interpretiere, dann habe die den RBO ebenso wie die
hints mehr oder weniger abgedreht (zumindest prüfen sie
mittlerweile, ob denn der CBO zum gleichen Ergebnis kommt, wie
der execution plan, der mit RBO/hints rauskommt).
ist ja eigentlich schon ein alter hut und oracle kündigte ja bereits für die 9er an, daß es rule based nimmer gegen wird …
Martin *derimherbstwiederdrachensteigengeht*
meiner ist schon hinüber … sch* bäume im böhmischen prater
grüße,
tomh