---

Wohl jeder Administrator hört gelegentlich die pauschale Klage seiner Anwender "Die Datenbank ist aber arg langsam geworden."
Nun sind weder Siemens/PLM noch unser Systempartner in der Lage, mir ein Prüfprogramm oder eine einfache Methode an die Hand zu geben, um eine nachvollziehbare Messlatte zu erhalten.

Eine Bitte um Mithilfe:

Um überhaupt mal ein Gefühl dafür zu bekommen, welche Antwortzeiten in einer "üblichen" Bandbreite liegen, bitte ich, folgenden Test auszuführen:
Die vordefinierte Suche "Item..." ausführen mit den Kriterien
Item-ID=* und Type=Item.
Bitte Anzahl der gefundenen Objekte und die Wartezeit vom Start der Ausführung bis zur Anzeige des Ergebnisses hier posten (Messung mit der Armbanduhr genügt vollkommen).

Meine Beobachtung:
Etwa 30.000 Items; die erste Ausführung der Suche dauert etwa 5 Minuten, eine Wiederholung binnen kurzer Zeit dauert etwa 15 Sekunden, nach einer Wartezeit von etwa 30 - 60 Minuten braucht eine weitere Wiederholung wieder 5 Minuten.
Nach Aussage unseres Systempartners beruht die hohe Wartezeit auf Plattenzugriffen für Datenbank-Tabellen.

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Nabbend,

vom CAD aus oder vom Richclient?

Servuz

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Gutn Morgen,

hab die Suche gerade mal durchgeführt mit folgendem Ergebnis:
gefundene Items: 37159
Dauer: 5sec
Es Werden dann immer nur 30items pro suchseite eingeblendet.
Wenn dann alle Komponenten eingeblendet werden dauert das
ca: 3min

------------------
gruß

Ralf

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

>>vom CAD aus oder vom Richclient?

Im Augenblick geht es mir alleine um TCE, also in dem Fall um den RichClient.
Das Laden einer Baugruppe aus dem CAD-System heraus kann sicherlich auch interessante Vergleichsdaten liefern, aber das braucht dann schon mehr Vorbereitung.

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

>>gefundene Items: 37159
>>Dauer: 5sec

Ralf,
das schaffen wir ja nicht einmal im Wiederholungsfall, wenn die Daten bereits im Zwischenspeicher sind.
Bitte erlaube mir eine neugierige Frage zu eurem Server:
64bit-Betriebssystem und wesentlich mehr als 2GB Arbeitsspeicher?

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

_search.jpg

Ich hoffe ich habe da auch alles richtig verstanden ! (siehe Bild)
Bis das suchergebnis erscheint (rechts) vergehen ca 3 sek.
(nur 30 Items) erst wenn ich dann alle 37000 einblende dauert das ganze dann ca 2-3 min.

Zur TCE umgebung: Datenbankserver ist ein Dualcore 32bit win2003 mit 4GB RAM auf dem nur die Datenbank läuft.
Fileserver ist ein W2K mit 2xXeon und 2GB RAM

------------------
gruß

Ralf

[Diese Nachricht wurde von subwoofer am 28. Aug. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

>>Ich hoffe ich habe da auch alles richtig verstanden !

Ja, danke.

>>(nur 30 Items) erst wenn ich dann alle 37000 einblende dauert das ganze dann ca 2-3 min

Ja, auch das ist klar.
Das ist aber nicht mehr die Wartezeit auf die eigentliche Datenbank-Abfrage, sondern das Laden der Seiten in der Benutzeroberfläche.

>>Zur TCE umgebung: Datenbankserver ist ein Dualcore 32bit win2003 mit 4GB RAM auf dem nur die Datenbank läuft.

Die Ausstattung entspricht unserer, nur dass wir eben auch das Plattensystem mit am gleichen Server haben.

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

In unserem NX4 testsystem hatten wir zu beginn astronomisch hohe Ladezeiten im NX.
Nach ca 4mon langer Analyse von UGS war die Lösung dann:

"index_verifier zeigte Dutzende von fehlenden Indizes. Nach Erstellen dieser funktioniert das System
wieder einwandfrei."

Nach erstellen der Indexe in der Oracle verkürzte sich die Ladezeit um einen Faktor von ~5x!

------------------
gruß

Ralf

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

 

Zitat:

---

Original erstellt von schulze:
.... folgenden Test auszuführen:
Die vordefinierte Suche "Item..." ausführen mit den Kriterien
Item-ID=* und Type=Item.
Bitte Anzahl der gefundenen Objekte und die Wartezeit vom Start der Ausführung bis zur Anzeige des Ergebnisses hier posten (Messung mit der Armbanduhr genügt vollkommen)....

---

Meine Umgebung:
6 Jahre alter Server der am Limit läuft, Win2003 32Bit, ich glaub 4 (oder 8 GB) RAM. TCE 2007 MP6, Volumes liegen auf lokalen Platten
Der Beschaffungsvorgang für den Nachfolger ist grad am Laufen ....

Der Server bedient nicht nur TCE, er hat noch eine weitere Oracle Instanz drauf und macht auch über eigene Daemons Translationservices (pvtrans, dxf, Plotfiles), diese fast permanent.

Das Ergebnis ist mit Vorsicht zu geniessen, da je nach Auslastung natürlich Unterschiede möglich sind:

1. Query, zusätzliche Einschränkung auf eine Owning Group, sonst muss ich fast ewig warten ...
17379 Items in ca. 6,5 Min.
Vorschau ist auf default von 30 Items gesetzt

2. Query nochmals dasselbe, kurz darauf,
17379 Items in ca. 2,5 Min.

Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

hi,

suche 1: 20s bis suchergebnis da, anzeige nach 25s (463924 items/1000 angezeigt)
suche 2: 10 sec für beides

das mit den indizes stimmt auf jeden fall. unsere oracleleute haben aber auch mal analysiert: für bestimmte tabellen lohnt es sich eigene indizes zu generieren - wir haben 4 stück anlegen lassen.
weiterhin sollte auch der indexverifier im oracle einmal wöchentlich laufen - der bringt gerade diese full-table-scans auf trab. bei oracle kann dir ugs auch nicht viel helfen - da gibt es seeeehr wenige leute, die dazu was sagen können.
im bereich nx hilft dir eine sql-optimierung weiter (ladezeitverkürzung von ungefähr 20% erreicht, bei bg-größen von 5000-15000 teilen).

nachtrag: nach 4 stunden 3.suche 18,2s - sind auch 6 items hinzugekommen...

------------------
Gruß aus Hamburg
 
Yeti

It's nice to be important, but it's more important to be nice! (Scooter in "Move Your Ass")

[Diese Nachricht wurde von Yeti am 28. Aug. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

>>Das Ergebnis ist mit Vorsicht zu geniessen...

ja,aber...

Unser Systempartner meint, mein Test sei als Performance-Indikator ungeeignet. Beim Laden von Produktstrukturen sei unser Server ähnlich schnell wie die von anderen Kunden.

Die beiden Daten, die ich von Ralf und Dir erhalten haben, geben mir aber einen vielleicht entscheidenden Hinweis:

Ralfs "Oracle-only"-Server ist vergleichbar mit unserem im Wiederholungsfall.
Dein "Alles-in-einem"-Server ist vergleichbar mit unserem.
Also sollten wir entweder die Datenbank von allen anderen Diensten trennen oder aber bei den heutigen 4fach-Cores mit einem Sertver arbeiten, aber deutlich mehr Arbeitsspeicher spendieren.

Bin mal gespannt, ob wir noch mehr Daten von anderen Anwendern erhalten!

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@ Yeti aus Hamburg
Gruss an die Deutschen Niederlande aus Frankfurt am Weisswurst-Äquator!

>>463924 items
Das ist natürlich eine wesentlich umfangreichere Datenbank als die unsere.
Deine Zeitangaben möchte ich also in eine Schublade mit denen von Ralf stecken.

>>das mit den indizes stimmt auf jeden fall....
Ja, das ist plausibel.
Aber unser fragwürdiger Renner kommt gerade von der Inspektion in der Tuning-Werkstatt.

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

bei uns sind es 540.000 teile.
wie lange die suche jetzt genau gedauert hat weiß ich nicht. hab nachher nicht mehr drauf geachtet, aber müssten 1,5 stunden gewesen sein 

sehr interessant in diesem zusammenhang ist noch die latenzzeit beim connect zur datenbank in der erweiterten syslog datei (bei aktivierter umgebungsvariable IMAN_SQL_MAGIC=YES und IMAN_SQL_DEBUG=BJPT).
dort steht etwa ab zeile 19:

    CONNECT;
      Oracle env: NLS_LANG=german_germany.we8iso8859p1.
      Oracle env: NLS_SORT=BINARY.
-->    err=0 rows=0 0.063 secs;
    **** Connected to 'xx' as 'infodba'

der secs wert zeigt die latenz an.
bei unserer testdatenbank (wo der tce server auf einer einfachen workstation läuft) liegt dieser wert beispielsweise bei 0.125 secs, also um einiges höher, was natürlich auf den langsameren "server" zurückzuführen ist.

wäre mal echt interessant wenn ihr diesen wert auch mal mit aufführen würdet, falls ihr die zeit dazu habt 

------------------
hab doch garnix gemacht .. außer den server neugestartet .. war das falsch? 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Yeti:
hi,

suche 1: 20s bis suchergebnis da, anzeige nach 25s (463924 items/1000 angezeigt)
suche 2: 10 sec für beides

---

oh man, ihr habt ja fast genausoviele items wie wir und bei uns dauert die über eine stunde.
ich glaub es wird dringends zeit das wir uns mal jemanden ins haus holen der unsere oracle datenbank tuned *G*
wir wollten erst bei ugs nach einem experten nachfragen, aber wenn du sagt das bringt eh nichts, kennst du da einen guten dienstleister? sind ja fast nachbarn  oder habt ihr intern jemanden dafür?

schöne grüße aus bremen 

------------------
hab doch garnix gemacht .. außer den server neugestartet .. war das falsch? 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Tomme

Unmittelbar nach dem CONNECT-Statement wir mir zwar eine Latenzzeit von 0.625s angezeigt, aber alle weiteren Angaben gesucht nach "err=0 rows=" schwanken zwischen 0 und wenigen Millisekunden - das sollte nicht unser Problem sein.

>>540.000 teile
>>müssten 1,5 stunden gewesen sein 

Unsere 5 Minuten x 540.000/30.000 kommt in die gleiche Grössenordnung, also scheinst Du ein ähnliches Problem zu haben wie wir.

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

suche 1: 125'438 Items in 470 sec.. (autsch! )
suche 2: nach ca. 60 Sekunden nochmals gesucht, 125'438 Items in 60 sec
suche 3: nach ca. 1.5 Stunden nochmal probiert ca 90 sec

Der Thread wird auch bereits durch unsere IT beobachtet.

Da sind wohl einige „neidisch“ auf Yeti’s Werte, ich auch.. 

------------------
MfG 
Pascal

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von passt1:
Hallo,

Da sind wohl einige „neidisch“ auf Yeti’s Werte, ich auch..  :D

---

jaa die haben mich auch schon ganz wuschig gemacht   

------------------
hab doch garnix gemacht .. außer den server neugestartet .. war das etwa falsch? 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

hi,

ist ja interessant, wie geduldig konstrukteure sein können/müssen. unsere optimierung ist eigentlich unseren großen baugruppen geschuldet, wenn ich von 5000 teilen rede, sind das unterschiedliche teile. mit wiederholteilen sind die baugruppen natürlich größer...
und da schreit natürlich jeder konstrukteur schon bei einer ladezeit größer 5min. wir arbeiten natürlich auch im nx mit ein paar "tricks" (outline laden statt baugruppe vollständig...), aber die performance ist teamcenterseits nicht das problem. eher unsere infrastruktur...

was ich vergessen habe, ist die verwendete hardware der server.
der oracleserver (mit 64bit-oracle) ist ein hp 585... (2 dual-core opterons mit 12gb speicher) unter einem suse sles 9.x (64bit). das plattenarray ist ein fibrechannel-scsi-array mit 15 platten, davon bilden jeweils 6 ein raid. plattenperformance (je mehr um so besser sagen die oracleleute) ist für das oracle wichtig. noch wichtiger ist aber der ram: wenn ich das richtig verstanden habe, ist der oraclecache der wichtige. und der ist dynamisch: je nachdem welche suchabfrage zuletzt gestartet wurde, ist das ergebnis im cache. das erklärt auch die zeit"erfolge" beim 2. lauf. diesen cache kann man im os für das oracle reservieren, je mehr tabellen im cache liegen, um so besser für abfragen. zur organisation des speichers: oracle braucht ca. 2-3 tage zur optimierung, deshalb ist ein cold-backup (=herunterfahren der datenbank) der datenbank tödlich für den cache. manche firmen machen das wegen datensicherung, aber da gibt es das hot-backup, das ist genauso sicher. uff, alles das ist nur im laufe zeit von unseren oraclespezis angeeignetes halbwissen - ich bin nur anwender des oracles!

dann haben wir noch einen fileserver, auch einen hp 385... (müssen wir wegen konzernvorgaben kaufen). auch ein dual-core opteron mit 4 gb ram aber einem größeren array (auch fibrechannel) unter windows 2003 server. auf dem laufen 3 parallele imanfs-prozesse: trotzdem langweilt sich die cpu und der ram ist leer. dafür ist der i/o öfters am anschlag, gerade morgens beim laden. aber das ist normal.

@tömme: wir haben interne mitarbeiter für das oracle, der darf nicht zum mitbewerber... aber ich kann ja mal bei externen dienstleistern nachfragen, ob da jemand lust auf bremen hat...

grundsätzlich bin ich auch schon stolz auf die erreichte performance, den anwendern reicht das natürlich noch laaaaange nicht...       

nachtrag @tömme: das sind auch nur die items, wir haben auch noch andere itemtypen...

eben habe ich mal nach itemrevisions gesucht (suchkriterien wie oben): 893092/55s für die erste, 36s für die zweite suche. also ist die anzahl noch ein kriterium.
grundsätzlich würde ich immer den oracle- vom fileserver trennen - siehe plattenzugriffe des oracles!

------------------
Gruß aus Hamburg
     
Yeti

It's nice to be important, but it's more important to be nice! (Scooter in "Move Your Ass")

[Diese Nachricht wurde von Yeti am 28. Aug. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

>>autsch!
>>Der Thread wird auch bereits durch unsere IT beobachtet

Hallo Pascal

Die Einfachheit meines Testfalls hat natürlich zwei Nachteile:
a) Der Test stellt eine Extremsituation dar, die nicht der täglichen Arbeitspraxis entspricht.
b) Der Test nimmt keine Rücksicht auf die von Firma zu Firma gegebenen Unterschiede der IT-Infrastruktur.

Aus der Sicht des Anwenders aber zählt alleine die Zeit, die er ungeduldig vor dem Bildschirm wartet. Und wenn mein Extremfall die Unterschiede übertrieben herausarbeítet, ist mir das nur recht.

------------------
R.Schulze

Yeti - danke für die ausführliche Beschreibung.
Ich bin auch kein Fachmann für Oracle, aber ist schon interessant, welche Erfahrungen Andere machen.

[Diese Nachricht wurde von schulze am 28. Aug. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

hi,

da wir gerade eine firmenteilung hinter uns haben, habe ich auch 2 datenbanken. auf zwei oracleservern.
der zweite hat bei der itemsuche folgende werte gehabt:
457784 items in 20s bei der ersten, 12,4s bei der zweiten suche.
33s bei 860843 itemrevisions, 24s bei der zweiten messung.
was mich stutzig macht, das er schneller ist - denn er ist der "alte" server (ca. 1 jahr älter). ansonsten natürlich ähnlich ausgestattet wie der neue, nur die cpu ist etwas langsamer... da werde ich morgen mal mit den oracleadmin reden.

------------------
Gruß aus Hamburg

Yeti

It's nice to be important, but it's more important to be nice! (Scooter in "Move Your Ass")

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo zusammen,

habe auch mal gemessen:

1. 198.220 Items in genau 240s bei 30 angezeigten    (Naja...  )

2. (nach ca. 1 Minute) 198.222 Items in ca. 280s        (Hmmm...  )

2a. (nochmal, ca. 30s später) 198.224 Items in 255s  (aha...  )

3. Habe ich nicht mehr durchgeführt, da ich keine deutliche Änderung/Verbesserung erwarte...

Zur Hardwareumgebung kann ich nix sagen, unser Admin ist schon weg...

Würde aber sagen, das ist noch steigerungsfähig!

------------------
Hoffeeinehilfegewesenzusein 

Gruß
Ralf

Improvisieren ist nur dann eine Kunst, wenn man nicht unvorbereitet aussieht...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

>>Naja

Na, das macht aber doch einen ganz passablen Eindruck.
Die Tatsache, dass die 2. & 3. Ausführung in etwa die gleiche Reaktionszeit wie die erste aufweisen, deute ich nach dem, was ich hier und heute gelernt habe, so, dass Dein Server zumindest kein Problem mit dem Oracle-Cache hat.

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

hi schulze,

ja, sehr interessant die diskussion.
habt ihr denn einen cache eingerichtet? wie schon beschrieben: der muß extra reserviert werden und steht dann dem os nicht zur verfügung. aber ich werde morgen mal bei der gelegenheit unseren oracleadmin fragen, wie das genau funzt.
im idealfall hältst du die gesamte db im arbeitsspeicher, das geht natürlich nur bis zu einer größe kleiner dem ram minus 1gb. unsere db ist irgendwas von 18 gb groß, auch da werde ich morgen mal fragen.
als schleichender killer hat sich der o.g. indexverifier entpuppt: wenn der nicht regelmäßig durchgeführt wird, bekommt der index nichts von den neuen items mit und macht einen full-table-scan. der load des servers steigt dabei sehr hoch und das gesamte system wird langsam. wenn dann der cache auch noch fehlt...
aber ich glaube, bei dir ist der gleichzeitige fileservice als bremse auch nicht zu verachten.
eine gute performancemessung ist im nx versteckt, wenn du nähere infos haben willst - PM...

------------------
Gruß aus Hamburg

Yeti

It's nice to be important, but it's more important to be nice! (Scooter in "Move Your Ass")

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von schulze:
[i[...]dass Dein Server zumindest kein Problem mit dem Oracle-Cache hat.
[/i]

---

Du meinst, weil keiner eingerichtet ist...?

Habe jedenfalls den Eindruck, dass wir auch noch eine Menge von Yeti lernen und selbst unser betagtes System noch besser auf Trab bringen könnten.

Jedenfalls vielen Dank für diesen hochinteressanten Thread! 

Gruß
Ralf

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

jaa ich hoff auch noch auf ein paar mehr denkanstöße 

bin langsam soweit doch keinen außenstehenden dienstleister ins haus holen zu lassen sondern eher eine oracle schulung zu besuchen damit man auch in zukunft selber weiß was man dort tut. wenn die nur nicht so EXTREM teuer wären *arghh*

------------------
hab doch garnix gemacht .. außer den server neugestartet .. war das etwa falsch? 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

>>eine oracle schulung zu besuchen
Nichts gegen eine Schulung.
Was nutzt Dir aber das erworbene Wissen, wenn Du keine Gelegenheit hast, es vor dem Vergessen wieder anzuwenden und zu pflegen?
Ich kenne Deine Arbeitsbedingungen nicht, aber wenn Du eher zur Seite der Anwender gehörst und nicht in Vollzeit als SysAdmin tätig bist, ist das wohl kaum die richtige Lösung.

------------------
R.Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

doch, bin Vollzeit CAD Administrator und gelernter Informatiker, von daher wäre das schon sinnvoll.
Wobei ich mir mal einige Schulungsangebote angesehen habe. Es gibt auch relativ günstige Schulunungen .. die Frage ist nur ob diese etwas taugen. Das Thema ist auch so extrem komplex das man wohl dennoch nicht um einen Oracle Spezialisten dumrumkommt der sich täglich damit beschäftigt. Nun muss man nur noch einen finden der möglichst nicht grad von UGS kommt *G*

------------------
hab doch garnix gemacht .. außer den server neugestartet .. war das etwa falsch? 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

hi tömme,

habe dir 'ne PM mit den kontaktdaten eines spezis geschickt.

unsere diskrepanz zwischen altem und neuen server sind durch eine falsche aufteilung des oraclespeichers begründet gewesen. der neue server war für den import der db optimiert und wurde danach nicht umkonfiguriert. das holen wir in 1 stunde nach...
also hat dieser beitrag auch bei uns eine optimierung ausgelöst...

------------------
Gruß aus Hamburg

Yeti

It's nice to be important, but it's more important to be nice! (Scooter in "Move Your Ass")

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

*hehe* das doch cool, dann profitierst du auch noch davon das du uns soviele tipps gibst. was will man mehr 

und danke für die kontaktdaten 

------------------
hab doch garnix gemacht .. außer den server neugestartet .. war das etwa falsch? 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

wir hatten gestern den herrn adler (der uns von yeti empfohlen wurde) bei uns und ich muss sagen, wir sind echt schwer begeistert.

die oracle datenbank war völlig falsch konfiguriert, die vorgaben von UGS bei der installation damals waren echt ein witz.

erstmal wurde das caching optimiert, in ein paar wochen kommt dann nochmal ein update von oracle und eine analyse wo fehlende indezes usw. gesucht werden.

------------------
hab doch garnix gemacht .. außer den server neugestartet .. war das etwa falsch? 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP