Wo eigentlich ANFANGEN mit der Entstörung?
|
|
| eröffnet am: |
07.06.09 12:57 von: |
Teras |
Anzahl Beiträge: |
3917 |
| neuester Beitrag: |
17.05.13 06:03 von: |
boersalino |
Leser gesamt: |
83683 |
|
davon Heute: |
15 |
bewertet mit 107 Sternen
|
Seite:
1 |
2 |
3 |
4 |
155 |
156 |
157
| 157
|
|
--button_text--
interessant
|
|
witzig
|
|
gut analysiert
|
|
informativ
|
107
Teras
: Wo eigentlich ANFANGEN mit der Entstörung?
07.06.09 12:57
In unübersichtlichen Gemenge-Lagen, wie wir sie hier bei uns auf ARIVA in Sachen Entstörung derzeit leider verzeichnen, weiß man oft gar nicht, wo einem der KOPF steht. - Das Kuddelmuddel hat sich SCHLEICHEND entwickelt, und wurde doch immer wieder SCHLAG-artig sichtbar wie in einer Blitzlicht-Aufnahme. - Die System-Ausfälle vom FREITAG (2.11.2007) wie der vom SAMSTAG (14.2.2009) oder auch der vom SAMSTAG (16.5.2009), um nur einige zu nennen, lieferten jeweils so ein Photo, das irgendwo in der Schublade gammelt.
Krise wurde allzu oft nicht als CHANCE begriffen; mit dem Ergebnis, dass heute keiner mehr sagen kann, seit WANN es nur noch eine BANK http://www.ariva.de/quote/...urse.m?branche_id=101&herkunft_id=-1 gibt und seit WANN denn nun nur noch drei http://www.ariva.de/quote/...rse.m?branche_id=5000&herkunft_id=-1 HEDGE-Fonds. - Unzählige "verlorene" Graphiken lassen sich immerhin noch DATIEREN, da ja der entsprechende Link vielerorts noch im System steht, was aber offenbar niemanden veranlasst, das ohne Moderation Ausgeblendete bitteschön wieder sichtbar zu machen.
Was wir derzeit beobachten müssen, ist eine Unterlassung notwendiger Arbeit und eine Zerstörung bereits geleisteter Arbeit. - Unzählige in mühsamer Kleinarbeit gefertigte und mit ARIVA abgesprochene Plaquetten sind durch actives Zutun noch immer verschrumpelt, manche bis zur Unlesbarkeit. - Und weil offenbar keine ENTSTÖRUNGS-Kladde führt wird, in welcher getätigte Entstörungen protocolliert und nach-beobachtet werden, sind wir seit Monaten des seltsamen Schauspieles ansichtig, dass eine Actie, die niemals in €uro quotiert worden ist, hier bei uns auf ARIVA 'mal in €uro geben wird, dann wieder in DEMark, dann wieder in €uro... - Arbeits-Beschaffungsmaßnahme ad infinitum.
Zerschrumpelte LOGOs, trotz nicht vorhandener CURS-Bewegungen wie wild in der Gegend herumspringende CHARTs, verlorene GRAPHIKen, die eigentlich nicht verloren sein müssten, gekappte VOLUMINA, zerschliffene SPREADs, deren Differenz von 0,10 auf 0,11 in ein und derselben Actie an ein und demselben Tage 'mal ZEHN und dann wieder NULL Procent ausmachen soll - irgendwann REICHT es!
Als ARIVA-Users sind wir ja treu. - Doch wenn wir immer neue Zumutungen ertragen müssen; nur, um ARIVA weiter die Treue halten zu können, dann wird es kritisch. - Wir wollen jetzt nicht mehr weiter zurück. - Und deshalb gehen wir jetzt gemeinsam nach VORNE.
Die Debatte ist eröffnet. - Liebe Grüße vom Teras. |
3891 Postings ausgeblendet.
8
Teras
: @Kronios: Ja, erst lesen, dann antworten ;-))
28.04.13 20:05
8
Teras
: Zum Thema der DURABILITAS, Teil 1:
29.04.13 10:55
Das Thema der DURABLITAS / durability / Durabilität oder Dauerhaftigkeit wird uns hier ja nun doch leider noch etwas länger beschäftigen müssen.
Zur Neubelebung der Discussion zunächst der Rückblick auf den ==> Rückholer vom 6.7.2009 zu #249 und #259.
LG: Teras. |
9
Teras
: Zum Thema der DURABILITAS, Teil 2:
29.04.13 11:05
Definition der Dauerhaftigkeit:
"Der Begriff Dauerhaftigkeit sagt aus, dass Daten nach dem erfolgreichen Abschluss einer Transaktion garantiert dauerhaft in der Datenbank gespeichert sind. Die dauerhafte Speicherung der Daten muss auch nach einem Systemfehler (Software-Fehler oder Hardware-Ausfall) garantiert sein. Insbesondere darf es nach einem Ausfall des Hauptspeichers nicht zu Datenverlusten kommen. Dauerhaftigkeit kann durch das Schreiben eines Transaktionslogs sichergestellt werden. Ein Transaktionslog erlaubt es, nach einem Systemausfall alle in der Datenbank fehlenden Schreib-Operationen zu reproduzieren".
Source / Link / Quelle hierzu: http://de.wikipedia.org/wiki/ACID#Dauerhaftigkeit |
9
Teras
: Zum Thema der DURABILITAS, Teil 3:
29.04.13 11:44
Selbstredend hat auch unsere Plattform ARIVA sogar mehrere solcher "Transaction Logs"; zumindest je einen für unsere beiden MASTER-DatenBanken, von denen die eine die secu-IDs aller hier geführten Finanz-Instrumente (Actien, Options-Scheine, Indices et cetera) und die andere die ABSOLUTEN Posting-Nummern aller hier eingebrachten User-Beiträge enthält.
Dennoch kommt es hier immer wieder zum VERLUST vorher bereits GESCHAUTER und auch bereits BEANTWORTETER und in ihrer Beantwortetheit sogar PHOTOGRAPHIERTER Foren-Beiträge...
Und das ist völlig inaccebtabel. |
8
Teras
: Streiche "inaccebtabel", setze: inacceptabel.
29.04.13 12:06
3
Kronios
: #896: ich darf bitte Zweifel anmelden Teras...
01.05.13 02:24
1) müssten wir den Begriff Datenbank klären... DB-Sys haben Logs typischerweise nicht auf der Ebene der "Datenbank" sondern des Datenbanksystems... wäre zu klären... 2) gehst du von ACID-DB's aus, das heisst nich unbedingt SQL... aber transaktionale DB's. Das bezweifle ich für den Teil der Postings... damit bezweifle ich auch die absoluten Postingnummern... ----------- a) Vertraue niemals irgendwelcher Hardware b) Ändere niemals irgendetwas am Computer |
5
Teras
: Zum Thema der DURABILITAS, Teil 4:
02.05.13 06:35
@Kronios: "2) gehst du von ACID-DB's aus, das heisst nich unbedingt SQL... aber transaktionale DB's"...
Ich muss nicht unbedingt von ACID-DBs "ausgehen", um CONSISTENZ und DURABILITÄT für WICHTIG zu halten! - "Reines" ACID erscheint mir ohnehin schwierig, irgendwas fällt da doch meistens aus eben dieser "Reinheit" nach hinten heraus...
Und Transactions-Logs sind in meinen Augen kein Monopol von "ACID"-DBs. |
5
starwarrior03
: Teras, uffgestanne jetzte.. looos.. Ariva hängt
03.05.13 10:05
| |
Angehängte Grafik:
master2.png (verkleinert auf 39%)


6
Bottleneck
: "Stored Procedures" vs "SQL Calls"
04.05.13 02:02
Verlagerung der Rechenleistung auf den DB-Server (Stored Procedures): http://de.wikipedia.org/wiki/Gespeicherte_Prozedur Verlagerung der Rechenleistung auf den App-Server (SQL Calls): https://de.wikipedia.org/wiki/Anwendungsserver
...Nachteil beim "SQL-Call" ist die Datenmenge, die durch's Netz geht sowie die Rechenzeit. Ein "SQL-Join" auf einen DB-Server (egal welche Programmiersprache) ist lastintensiver als ein "Stored Pocedure", der direkt auf dem DB-Server ausgeführt wird. Allerdings ist es im Bankenumfeld immer noch üblich diesen Weg aus "sicherheitstechnischen" Gründen zu gehen (BaFin)... |
8
Teras
: "Auf Antwort von ariva.de wird gewartet"...
04.05.13 04:40
Ich erhielt in denen letzten Tagen ein Dutzend Male, und zwar immer beim LINK Einfügen, die folgende System-Info:
"Fehler 502 Beim Erstellen der von Ihnen angeforderten Seite ist ein Fehler aufgetreten.
Der Server hat die Verbindung unerwartet beendet oder brauchte zu lange, um eine Antwort zu senden.
Falls das Problem temporärer Natur ist, können Sie die Seite noch einmal anfordern. Sie können auch zur Startseite zurückkehren.
Unsere Administratoren wurden bereits über das Problem informiert. Wenn Sie weitere Fragen haben, können Sie uns mit einer E-Mail an support@ariva.de kontaktieren".
LG: Teras. |
7
Teras
: "Fehler 502" als "nasse INSEL":
04.05.13 05:35
Wir haben nach der Steigerung der GRUND-Stabilität, die sich als erfreuliche FOLGE des am Vormittag des 27.3.2013 vollzogenen Wechsels des HARD-Master's eingestellt hat, also immer noch mit Time-out-Errors 502 ein wenig zu kämpfen...
Fehler-überhäufte Bereiche gelten Entstörungs-systematisch als "NASS"; doch immerhin ist dieser vom Time-out-Error 502 heimgesuchte Bereich inzwischen sehr stark verinselt, denn früher war der 502er ja noch UBIQUITÄR:
http://de.wikipedia.org/wiki/Allgegenwart |
4
0risk0fun
: welcome back Entstörer
04.05.13 19:04
hihi, alles Grosse Grosse Buchstaben beim Bewerten, grööööl
dafür kann ich kaum mehr "innovativ" klicken.... hach
:o)))))))))))))))) ----------- Der Berg ist hier zu Ende. Höhersteigen auf eigene Gefahr! |
7
Teras
: Hallo, Risky: Welcome back!
04.05.13 19:10
8
Teras
: Zur "NASSEN Insel" des Fehlers 502...
05.05.13 04:50
... gibt es Ariva-seitig seit Längerem eine interne DISCUSSION, was ja auch nicht sonders verwundert, da das BugFix-Department bei JEDEM Auftreten dieses Fehlers automatisiert BENACHRICHTIGT wird, was die Ariva-Maschine mit "Unsere Administratoren wurden bereits über das Problem informiert" dem User dann jeweils ausdücklich QUITTIERT; vergleiche HIER:
==> "Auf Antwort von ariva.de wird gewartet"...
Die entsprechenden System-Einträge dürften in die Hunderte gehen; nur mir allein wurde die zugehörige System-Antwort schon an die 20 Male zu Teil, so dass das fette 502er Problem kaum unbemerkt geblieben sein kann.
Dieser Fehler correspendiert auch mit einer ganz ähnlichen System-Meldung, die ebenfalls beim Link EINFÜGEN auftritt:
(Angehängte Graphik: 2013-05-04-Wegen-zu-langer-Wartezeit-abgebrochen.PNG). |
Angehängte Grafik:
2013-05-04-wegen-zu-langer-wartezeit-....png (verkleinert auf 98%)


8
Teras
: Noch zur "NASSEN Insel" des Fehlers 502:
05.05.13 05:27
Des Öfteren befindet sich beim fehlschlagenden LINK Einfügen ein weiteres Fenster HINTER dem Fenster des geplanten Beitrages; wessen der User aber oft gar nicht gewahr wird, da sich das durch sein Beitrags-Fenster VERDECKTE erst zeigt, wenn die NORMALE Größe des BEITRAGS-Fensters künstlich auf 50% reduciert wird, wodurch das DAHINTER Liegende dann plötzlich in den sichtbaren Bereich gebracht werden kann.
Man beachte die hier nur Ausschnitts-weise wiedergegebenen blauen Streifen links und rechts des Überlagerungs-Geschehens, das sich im CENTRUM des Bildschirmes abgespielt hatte, so dass wegen der zu Test-Zwecken vorgenommenen Verkleinerung des Beitrags-Fensters die zu jenem Zeitpunct BLAUE Hintergrund-Farbe der Seite hervortrat:
(Angehängte Graphik: 2013-05-04-Anzeige-hinter-dem-Beitrags-Fenster.PNG). |
Angehängte Grafik:
2013-05-04-anzeige-hinter-dem-beitrags-fenster.png (verkleinert auf 77%)


8
Teras
: Nochmals zur "nassen Insel" des Fehlers 502:
05.05.13 07:00
| In der dem vorstehenden Beitrag documentierend angehängten Graphik fällt auf, dass sich vor "Artikel-, Video- oder Bild-Link" ein grüner HAKEN befindet; trotzdem dann die Warnung: "Keine Antwort vom Server. Der Vorgang wurde aufgrund zu langer Wartezeit abgebrochen. Bitte aktualisieren Sie die Seite", was aber nichts bringt... |
7
Teras
: Es bringt im Übrigen auch gar nichts,
05.05.13 09:05
... sich den per LINK Einfügen zur Einbringung vorgesehenen Beitrag vermittels der VORSCHAU nochmals anzeigen zu lassen; dann wird zwar ebenfalls "Alles OK" angezeigt, was aber nichts an der Tatsache ändert, dass wiederum die schon
HIER ==> "Auf Antwort von ariva.de wird gewartet" documentierte Meldung erscheint.
(Angehängte Graphik: 2013-05-05-Alles-OK-ist-NICHT-okay.PNG). |
Angehängte Grafik:
2013-05-05-alles-ok-ist-nicht-okay.png

6
Teras
: Was aber vielleicht helfen könnte:
05.05.13 09:30
Den grünen HAKEN und das "Alles OK" und das "Auf Antwort von ariva.de wird gewartet"
... gar nicht erst AB-zu-warten, sondern den LINK direct in's System durchzudrücken.
Einen TEST wäre das alle Mal' wert ;-)) |
7
Teras
: "Der TEST der Enteignung kommt":
05.05.13 09:35
Mittlerweile ist salonfähig, was vor kurzem noch ein Privileg der Verschwörungstheoretiker war. |
6
Teras
: Na, ALSO! - GEHT doch!
05.05.13 10:45
Dennoch ist diese "Lösung" in höchstem Maaße unbefriedigend, und zwar aus 3 Gründen:
Erstens: Unsere Plattform teilt es ihren Users ja nicht MIT, dass direct DURCHGEDRÜCKT werden muss, falls ein LINK eingebracht werden soll! - Die officielle Anweisung verlangt vielmehr, dass zunächst die VORSCHAU zu betätigen sei, falls ein Einfügen fehlschlägt, oder, dass zunächst auf "neue Beiträge" zu prüfen sei - und all' dieser Schmonzes.
Zweitens: Beim directen DURCHDRÜCKEN des LINK Einfügens kann der User nicht entscheiden, welches PHOTO des durchgedrückten Artikels erscheint, wie man im obigen Beitrag auch ganz deutlich sieht, in welchem vor "Mittlerweile" ein nichtssagendes Photo steht.
Drittens: Wurde schon unter ==> Und drittens... erläutert.
LG: Teras. |
4
Teras
: Eine echte LÖSUNG hingegen...
06.05.13 06:06
... scheint sich seit Kurzem für das schon etwas ältere Problem abzuzeichnen, dass bereits GEZEIGTE Curse im Nachhinein wieder VERUNSICHTBART wurden, durch welches ärgerliche Phaenomen uns zuletzt die Curse vom DIENSTAG (30.4.2013) einfach weggeplättet wurden.
Hierzu einfach 'mal die ScreenShots ab ==> "Börsen-Feiertag 30.4. für Mindspeed?" durchclicken, dann wissen Alle, über was wir hier reden.
Früher wurden derartige Fehler ja allen Falles immer und immer wieder einzeln BEHOBEN (öfters auch NICHT); doch seit Kurzem gibt es hierzu einen tragfähigen Vorschlag seitens ARIVA, der mir auf Grund seiner logischen Consistenz durchaus geeignet erscheint, uns das leidige Problem nunmehr dauerhaft zu ENTSTÖREN.
Ich werde die Umsetzung des Vorschlages beobachten und natürlich ergänzend berichten.
LG: Teras. |
2
da liegt wohl ein missverständnis vor... ein join kostet Zeit... ja... aber deine Aussage ist nicht so ganz richtig...
nehmen wir mal SQl-Server: Beispielcode SELECT FROM Feld TABLES Daten, Joindaten Where x=y INNER JOIN ... blabla.. Wenn ich einen SQL-CALL mache, dann macht SQL-Server einen Ausführungsplan. Der beruht auf dem Call. Ich möchte einfach mal sagen - obwohl es technisch nicht korrekt ist - der Call wird interpretiert. Wenn ich eine Stored procedure aufrufe mit dem selben Statement, dann macht SQL-Server auch nen Ausführungsplan. Allerdings wird der optimiert insichtlich der DB. Der Ausführungsplan wird zusammen mit der Porcedure gespeichert. Ich möchte das mit einer "kompilierten" Abfrage vergleichen.
Vereinfacht: bei einer SP wird der Overhead der Abfrage im Hintergrund generiert, darum läuft die dann schneller. Bei einem einfachen Call - möchlichst noch über Agents - wird der Overhead bei jedem Aufruf "just-in-time" fällig".
Der Unterscheid den DU meinst ist ein anderer... ich kann jederzeit über RFC einen Call auf dem Server machen. Kein Prob. Da brauch ich nur die Rechte. Zum Datenzugriff. Eine Stored-procedure zu machen... da brauch ich Verwaltungsrechte auf dem DB-Server. Und nicht nur auf die Daten. Deshalb machen Banken im Business mit anderen Calls.. und bei sich selber SP's.
@Teras: ein 502 bringt mich derzeit nicht zum Staunen... ----------- a) Vertraue niemals irgendwelcher Hardware b) Ändere niemals irgendetwas am Computer |
5
Teras
: Ich habe jetzt den RESTE-Fehler moniert,
14.05.13 16:05
5
Teras
: Juhuh: Der RECHEN-Fehler ist gefunden!
15.05.13 06:45
6
boersalino
: Ich hatte mich sooo an den Alu-Chart gewöhnt
17.05.13 06:03
| War auch ganz nützlich, alldieweil Aluminium im Tagesverlauf oft ein zuverlässiger Früh - Indikator für Gold war. |
Seite:
1 |
2 |
3 |
4 |
155 |
156 |
157
|
157
Antwort einfügen -
nach oben
4 Nutzer wurden vom Verfasser von der Diskussion ausgeschlossen:
Happy End, Herr klug - schlau, MikeOS, Rene Dugal