moo_kuh

Ich möchte aber nur ein reines Modem ohne Router/WLAN und den ganzen Quatsch. Gibts sowas in der heutigen Welt noch - ich hoffe doch. Viele Grüße

Hallo Kollegen, ich habe gerade wieder eine riesen Aktion, mit der T-Com, da sie einfach nicht fähig sind mir ein passendens Modem zu schicken. (habe nen Splitter bekommen!) Es ist wirklich zum Eingraben :old :old Nungut... also in der kommenden Woche wird auf 6000 bei mir umgestellt, da mein alter 1000er Vertrag ausläuft. Laut Telekomauskunft funktioniert mein altes Modem (noch ein Siemens Modem der ersten Generation!) mit 6000 nicht mehr. In andere Foren habe ich aber schon was anderes gelesen. Nun meine Frage an Euch: Welches externe Modem ist 6000-fähig? Ich benötige nur ein Modem ohne W-LAN, etc.. bei E-Bay habe ich folgende Endgeräte gefunden: eBay: Teledat 300 LAN Modem DSL 6000 fähig Komplett in OVP (Artikel 300110530565 endet 21.05.07 15:30:25 MESZ) eBay: Teledat 302 DSL Modem bis 6000 kbs (Artikel 330119578044 endet 20.05.07 18:46:14 MESZ) Wer von Euch hat schon 6000 und welches Modem verwendet ihr bzw. mit welche Speed könnt ihr dann saugen? Evtl. hiermit den Speed testen? -> DSL Speed-Test: Upload und Download Geschwindigkeit bei DSL testen Vielen Dank!

Hallo Kollegen, Oracle erlaubt es ja TEMP-Files im laufenden Betrieb zu löschen. Dabei stelle ich mir eigentlich folgende frage: Wie handelt Oracle die benötigten "aktiven" Temp-Segmente (von laufenden Sorts,Joins,etc..) die gerade in dem Tempfile liegen? Ich stelle mir gerade folgendes vor: Ich habe einen TEMP Tablespace als Default für die Datenbank und die User gesetzt. Dieser beinhaltet 2 Tempfiles. Ein User macht gerade einen Join und einen ORDER BY von 2 großen Tabellen, so das Speicher im TEMP Tablespace allokiert werden muss. Es werden 2 Segmente aus dem Tempfile1 und 3 Segmente aus dem Tempfile2 allokiert. Nun droppe ich im laufenden Betrieb das Tempfile2 ... Was passiert mit den 3 allokierten Segmenten? Die Query läuft während des ganzen DROP Vorgangs noch.... Bekomme ich dann einen ORA Error oder wie wird das gehandelt? Vielen Dank! Gruß

So habe ich das bisher auch verstanden. Durch das Flag erkennt Oracle das die aktuelle SCN aus dem aktiven Redolog nicht mehr verfügbar ist und liest die jeweiligen letzten SCNs aus den Headern der Datenfiles und recovered dann bis zu einem "cancel" oder "until". Hätte ich noch ein aktuelles intaktes controlfile könnte ich ein einfaches "recover database" machen, da Oracle noch weiss wie weit er zum kompletten recover heranfahren muss (vorrausgesetzt ich hätte noch die aktuellen Redologs). Ist das korrekt? Das ist korrekt.. unsere Backupsoftware benutzt aber noch das "alter database backup" kommando und unser softwarelieferant gibt bisher auch nur für diese Methode Support. Für unsere anderen Oracle Installationen haben wir RMAN im Einsatz. Danke

Hallo Kollegen, ich habe mal eine kleine Frage zum Thema Backup Controlfile. Es gibt ja 2 Möglichkeiten ein Backup vom Controlfile zu erstellen 1) alter database backup controlfile to trace 2) alter database backup controlfile to 'FILENAME' Zu 1) Hier kann ich die Datenbank evtl. umbennen oder gewissen Einstellungen korregieren die man sonst nicht mehr ändern kann. Das "Controlfile" ist im Klartext. Aus diesem File erzeuge ich dann wieder die binären Controlfiles Zu 2) Das ist eine binäre Kopie des Controlfiles. Und nun meine Frage: Wenn ich eines der beiden "Controlfiles" benutzen will, soll man ja die Datenbank mit "recover database using backup controlfile" wiederherstellen. Mir ist aber ganz ehrlich gesagt nicht klar, was der IDENTIFIER "using backup controlfile" für einen Sinn hat? Wenn ich z.B. das Controlfile aus Punkt 2 nehme, ist es doch nicht unterschiedlich wenn ich Datenbank restoren will (gut die fortlaufenden SCNs, Sequenznummer der Redologs unterscheiden sich).. aber das bekommt Oracle doch auch hin, wenn ich nur "recover database" mache, oder? Bei Punkt1 leuchtet es mir auch nicht ein, da ich aus der Tracedatei wieder die Controlfiles erstelle (gut die SCNs, Sequenznummern gibt es überhaupt nicht mehr), aber das bekommt Oracle ja auch hin, wenn ich nur "recover database" mache, oder? In beiden Fällen öffne ich die Datenbank mit OPEN RESET LOGS. Kann mir vielleicht mal jemand den genauen Sinn von IDENTIFIER "using backup controlfile" erklären und worin der Unterschied zu einem recover ohne diesen Zusatz liegt? In beiden Fällen wurde ein Onlinebackup erstellt und das "Backup" des Controlfiles mitgesichert. Vielen Dank

Ja das ist schon klar aber als übertriebenes Beispiel "Clustering Factor = Anzahl rows in Tabelle", dann macht es ja keinen "Sinn" den Index zu verwenden, außer man möchte nur einen Wert der Unique ist oder nur einen kleinen "Range" selektieren. Will man verschiedene Ranges haben... dann relativiert sich das ganze natürlich Also danke nochma für deine gute Erklärung :nett:

Dachte ich es mir doch :beagolisc Ab welchen "Verhältnis" wird denn ein Fulltablescan einen Indexzugriff vorgezogen? Gibt es dafür irgendeine Faustregel bzw. einen prozentualen Wert des Clustering Factors auf die Rows?

Super Erklärung! :uli :nett: Mit diesem Verständnis kann man dann auch folgendes Dokument gut nachvollziehen: DBAzine.com: Oracle Index Clustering Factor Btw. es ist immer die Rede von "Leaf-Blocks"... werden so die "Datenblöcke" von Indezes bezeichnet? oder was kann ich unter "Leaf-Blocks" verstehen? Vielen Dank. :byby:

Hallo Leute, ich versuche gerade den "Clustering Factor" von Index zu Table zu verstehen. Bisher habe ich leider nur englische Dokumente gefunden, die mir das ganze bisher aber noch nicht "verständlich" rübergebracht haben. Habt ihr vielleicht ein paar deutsche Dokumente zu dem Thema oder vielleicht ein paar Links dazu? Wäre super... Danke die moo_kuh

Hallo Jungs, ich habe noch eine ergänzende Frage zu den UNDO Segmenten mit Automatic Undo Management... und zwar folgendes: Nach welchen Regeln gehen die Segmente Online bzw. Offline? Solange die Transaktion noch nicht commited ist bleibt das Segment mit den "Snapshot des alten Wertes" auf jedenfall online, aber danach? Geht es sofort offline nachdem die Transaktion commited wurde, oder bleibt es noch die undo_retention online? Oder bleibt das Segment sogar noch länger online, wenn ein "SELECT STATEMENT" noch den alten Snapshot benötigt? Danke Bei Automatic Undo Managment gibt es doch nur die 2 Statis? (ONLINE und OFFLINE) Gruß die moo_kuh

Ahhh! Wenn das so ist, dann ist es natürlich ziemlich clever Ich denke mal, das war früher aber mit den Rollbacksegmenten das selbe, wenn sie "verloren" gegangen sind/wären (habe bisher eben nur mit dem Automatic Undo gearbeitet) Naja nu is ja alles klar... Vielen Dank Jasper :nett:

Oha... das ist ja ziemlich "übel". Gut für die Performance mag es nicht schlecht sein aber nach meinen Verständnis passiert doch folgendes: Der SMON Prozess allokiert ja beim Start der DB X Undo-Segmente (abhängig von den Sessions Parametern). Er verwaltet ja auch während der Laufzeit die Segmente (setzt online, offline, allokiert neue für jede Transkation etc...).. soweit so gut... Ich kopiere mal aus der Doku: Und nun meine "Theorie": Wenn die Undo-Segmente genauso gehandhabt werden wie normale Datenblöcke, werden sie ja zuerst in der SGA (Buffer Cache) editiert/geupdatet und dann nach einen CKP-Event in die Datenfiles geschrieben. Nebenbei werden alle Statements ja auch im Redolog mitprotokolliert. Das heisst die DML Statements im UNDO Tablespace selbst benötigen keinen Commit oder werden gleich commited, da im Falle eines Recovers die Einträge im UNDO Tablespace ja nicht commited wären und somit evtl. nichts zurückgerollt werden könnte. (für nicht commitete transaktionen!) Beim Recovery werden ja erst die Redologs (bzw. Archivelogs) applied und dann die nicht commiteten Transkationen mit Hilfe des UNDO Tablespaces zurückgerollt... wenn die Daten aber im UNDO Tablespace noch nicht durch ein CKP-Event geschrieben wurden, müssen diese ja auch aus den Redologs applied und commited werden.. Benötigen Daten im UNDO Tablespace also keinen Commit oder wie funzt das? Danke :uli

Wenn wir gerade den Thread erweitern, hätte ich auch noch ne Frage: Allokieren die Schattenprozesse direkt Undo-Segmente? Damit meine ich z.B. wie temp-segmente im Temporary Tablespace. Oder funktioniert das über den DBWR oder über einen anderen Oracle Prozess? Vielen Dank

Hallo Kollegen, ich beschäftige mich gerade intensiver mit den Thema Oracle Datenbanken (notgedrungen) und habe gerade viele Artikel über das UNDO Management gelesen. Da ich mit Oracle 9i angefangen habe und dort bisher auch nur das AUTOMATIC UNDO Management verwendet habe, wollte ich mal wissen was für Vorteile das manuelle Management mit sich bringt (Rollbacksegemente). Aber ich konnte eigentlich bisher keinen Vorteil der "manuellen" Methode entdecken. Es ist nur mehr Aufwand die Größen und Anzahl der Rollbacksegmente zu pflegen. Den einzigen Vorteil, den ich mir im Moment vorstellen könnte ist, das ich einer Transaktion ein bestimmtes Rollback Segment zuweisen kann, und ich für verschiedene Anwendungsbereiche verschieden große Rollbacksegemente habe bzw. gebe. Aber sonst? Vielleicht könnt ihr mich mal aufklären und wieder ein bischen schlauer machen :confused: Grüße die moo_kuh

Hi, naja ohne ein paar Codeteile werden wir dir kaum weiterhelfen können Welchen Socket Typ verwendest du denn? Socket Types and Protocols Gruß moo_kuh