Firebird nach Microsoft konvertieren

[iki]

Hallo,

wir haben eine Datenbank von 600Mb.
Die Anzeige von Listen ist teilweise langsam. (ca 6000 Zeilen)
Deshalb tragen wir uns mit dem Gedanken auf Microsoft Datenbank umzustellen mit der
Hoffnung dass das dann schneller geht.

Ich suche eine Firma die das für uns machen kann.
Wer kann mir Adressen nennen?

Vielen Dank.
Gruß Iki

[defo]

wir haben eine Datenbank von 600Mb.
Die Anzeige von Listen ist teilweise langsam. (ca 6000 Zeilen)
Deshalb tragen wir uns mit dem Gedanken auf Microsoft Datenbank umzustellen mit der
Hoffnung dass das dann schneller geht.

Da sollte nichts langsam sein, außer Ihr arbeitet mit 6000 Benutzern auf der Datenbank oder einem älteren Pentium 2 System.
Interessant wäre, mit welchen Zugriffsverfahren Ihr arbeitet, welche Art Anwendung ihr auf die DB loslasst.
Ist das schlecht umgesetzt, hilft der Tausch der DB nicht (sofern er überhaupt ohne weiteres möglich ist).

Achso, was bedeutet eigentlich langsam?

Ich suche eine Firma die das für uns machen kann.
Wer kann mir Adressen nennen?

Ich könnte Dir unsere Adresse schicken, aber ich würde mich schämen, aufgrund Deiner Aussagen einfach tätig zu werden und eine schnelle Mark zu machen.

[tömmel]

Da würd ich mich zur not auch aus dem Fenster hängen, dass die Datenbank da nicht ob der schieren Datenmasse in die Knie geht - nicht das ich jetzt Firebird Spezialist wäre - aber 600MB an Daten sind ja nun nicht die Welt - und den MS-SQL Server kann man auch den Anker rein hauen, wenn man z.B den Indexe nicht oder nach Wetterlage setzt ...

Ich würd da Anwendung und Datenbank mal unter die Lupe nehmen bevor eine Verzweifelungstat ansteht...

Was sagt denn der Hersteller der Anwendung?

(ich gehe mal davon aus ihr habt sie nicht selbst erstellt, sonst würdet ihr sie ja auch selbst die DB portieren - was ja hauptsächlich dann spannend wird, wenn ihr viel in T-SQL übersetzen müsst - oder die Anwendung sich irgendwo auf Firebird festgelegt hat.....)

[Bernhard Geyer]

wir haben eine Datenbank von 600Mb.
Die Anzeige von Listen ist teilweise langsam. (ca 6000 Zeilen)
Deshalb tragen wir uns mit dem Gedanken auf Microsoft Datenbank umzustellen mit der
Hoffnung dass das dann schneller geht.

Hoffen und nicht wissen was die Ursache ist wird in einer Herben Enttäuschung enden.
Bei einer solchen (in 2013 für richtige SQL-Server) kleinen Datenbank schaut es eher nach Implementierungsfehlern/fehlenden Optimierungen der SW-Entwickler aus als das die DB-Engine hier an Ihre Grenzen kommt.

[iki]

Guten Morgen zusammen,

zuerst vielen Dank für Eure Beiträge.
Ihr habt recht, ich weiß nicht wo der Engpass ist. (ich bin nur der Client)
Der Hersteller sagt, es geht nicht schneller, da müssen wir auf schnellere Hardware warten.
Indexe sind gesetzt. Wo und welche weiß ich natürlich auch nicht.

Zur Geschwindigkeit.
Wir können die Listen selber anpassen, das bedeutet, dass wir selber festlegen können, welche
Daten in den Liste stehen. Gehen wir mal davon aus, dass wir alle Aufträge sehen wollen (6000 Zeilen)
Das geht sehr schnell. Wenn wir dazu z.B. die Rechnungsnummern anzeigen wollen, müssen wir in ein
anderes SQL Verzeichnis um die Daten zu hohlen. Je tiefer oder je mehr verschiedene Verzeichnisse
wir benutzen, desto langsamer wird es. z.B. zwei sec. bis die Liste angezeigt oder umsortiert ist.

Der Server ist ein.

HP ProLiant ML330T06 (G6) / Intel Xeon X5650
6-Core 2.66 GHz, 12MB L3 Cache, 1333Mhz
80W, DDR3-800,
SAS Hot Plug Modell / 16 GB bestehend aus 4 x 4GB
MEMORY KIT DDR3-1333 RDIMM 1RX4 PC3-10600R-9
KIT / Tower / HP SmartArray P410 Raid-Conroller 512
Mb Cache batteriegepuffert, 2 x 300 GB SAS 6.0Gb/s
HDD (SYSTEM) 15000 rpm + 2 x 300 GB SAS 6.0Gb/s
HDD (DATEN) 15000 rpm, SATA-DVD-ROM Laufwerk,

Gruß
Iki

[defo]

Das klingt doch spannend, dynamischer Abfragenaufbau?
Jetzt nochmal:
Welche Softwaretechnology?
Webanwendung mit Application Server?
C# oder anderer Fat Client?

[tömmel]

Der Hersteller sagt, es geht nicht schneller, da müssen wir auf schnellere Hardware warten.
Iki

Nicht für Geld und und gute Worte

Naja . ich kann jetzt nur Kaffeesatz lesen und raten .- mach ich hier öfter und bekomm dann haue - tu ich aber wieder trotzdem :

Da es im Bereich des Repoting ja so hakt und ihr eure Berichte 'selbst erstellt' denke ich mal, dass ihr ein Reportingtool benutzt, das die Daten direkt aus dem Produktivsystem zieht.

Problem bei sowas ist oft, dass dort die Daten so vorliegen, dass (ich nenn's mal so) der Laie nicht ohne weiteres die Daten so aufbereiten kann, wie er es braucht.

Wie gesagt, geraten - zur Verfügung steht dann schon ein Set von Sichten, mit dem das Reportingtool dann weiterhantiert...


Das muss was die Abfragegeschwindigkeit angeht, nicht immer was gutes bei herauskommen.


Wegen sowas packt man ggf. tatsächlich die Daten salopp gesagt in eine Zwischenschritt in ein "Datawarehouse' (in Anführungsstrichen) oder wenn es immer die selben Berichte sind die Nerven aufreibend sind und regelmäßig gebraucht werden, ggf. einen Weg suchen diese ohne das Reportingtool zu erhalten.....

So jetzt können wieder alle schimpfen kommen...


PS.: ggf. kann der MS-SQL Server da dann doch helfen - nicht wegen der Datenbankengine sonder eher wegen den Tools zum Berichtswesen drum herum, aber das ist eine andere Kiste - ich gehe mal davon aus das Reporting ist hier in eine Anwendung 'eingebaut' ?

[iki]

Hallo
>dynamischer Abfragenaufbau?
Wenn Du damit meinst, dass wir ständig die Listen ändern, dann ist das nicht so.
Aber wir können, wenn wir es benötigen, zusätzlich Datenfelder in den Listen anzeigen lassen.

>Welche Softwaretechnology?
Die Anwendung ist in Delphi programmiert.

>Webanwendung mit Application Server?
Die Anwendung läuft Client PCs und holt sich die
Daten vom Firebird Server.

>das Reporting ist hier in eine Anwendung 'eingebaut' ?
Es wird kein externes Tool verwenden. Die Software zeigt einfach Listen an.
Alles was dazu notwendig ist, ist von der Softwarefirma selber programmiert.

Ich hoffe ich konnte die Fragen gut beantworten?

Gruß
Iki

[tömmel]

Auch wenn ihr die Listen nicht ständig ändert, sind die abfragen sehr wahrscheinlich 'dynamisch zusammengebaut', - sprich nicht vom Hersteller vorgegeben...
ber
Ich weiss, das ist schwer zu verstehen, das hat man mit jedem Kunden :

Jeder Kunde möchte gefühlte 27 Millionen Statistiken haben, die das Altsystem ja auch konnte - so kommt man in die Verlegenheit entwedert individuell sowas zu erstellen oder aber Werkzeug zu überlassen für's do it yourself...

Ist jetzt etwas schwierig zu erklären, weil es verschiedene Abwägungen gibt welchen Weg man da ggf. geht ... ihr habt scheinbar ein 'selbstgebautes' tool des Herstellers um Abfragen zu generieren.... das ist sowas wie ein kompromiss zwischen 'einfacher Bedienung' und Leistungsfähigkeit.

Das war das, was ich meinte mit Tools um den SQL-Server -nur so zur Einordnung - der bekommt schon OLAP Service mitgeliefert - was aber nicht bedeutet, das diese Analysis Services selbsterklärende Wollmilchsäue sind. Sie sind aber genau wegen dieser Problemlage entstanden (natürlich nicht nur bei und von MS - das ist ein eigener Markt)

Fakt ist - die Daten stehen i.d.R. nicht so in den "Tabellen", wie ein User sich das vorstellt - entsprechendes Kknowhow muss vorhanden sein, wenn man Honigausden Daten ziehen will.

Hoffe etwas verständlich geschrieben zu haben - bin mir aber nicht sicher ob rüberkommt, was ich sagen will...

Problem wird sein, das durch da tool ihr zwar flexibel seit aber die Abfragen nicht optimal (es ist schwierig sowas zu bauen ass es wirklich flexibel , benutzbar undschnell ist) deshalb s.o.

[iki]

Ich versteh das Problem, und kann auch Deinen Ausführungen folgen.

Für mich stellen sich zwei Fragen.
1. Würde Microsoft SQL ein schnellere Ergebnis liefern, auch mit Hinsicht, dass wir erst zwei Jahre mit dem
neuen System arbeiten und die Daten mehr werden.

2. Welche Fachfirma kann sich die SQL Abfrage ansehen und ggf. sagen wo ein Index gesetzt werden müßte?

Die Softwarefirma währe sicher für Verbesserungen offen, ich denke ein Zusammenarbeit ggf. auch.

[defo]

Zur Geschwindigkeit.
Wir können die Listen selber anpassen, das bedeutet, dass wir selber festlegen können, welche
Daten in den Liste stehen. Gehen wir mal davon aus, dass wir alle Aufträge sehen wollen (6000 Zeilen)
Das geht sehr schnell. Wenn wir dazu z.B. die Rechnungsnummern anzeigen wollen, müssen wir in ein
anderes SQL Verzeichnis um die Daten zu hohlen. Je tiefer oder je mehr verschiedene Verzeichnisse
wir benutzen, desto langsamer wird es. z.B. zwei sec. bis die Liste angezeigt oder umsortiert ist.

>Welche Softwaretechnology?
Die Anwendung ist in Delphi programmiert.

>Webanwendung mit Application Server?
Die Anwendung läuft Client PCs und holt sich die
Daten vom Firebird Server.

>das Reporting ist hier in eine Anwendung 'eingebaut' ?
Es wird kein externes Tool verwenden. Die Software zeigt einfach Listen an.
Alles was dazu notwendig ist, ist von der Softwarefirma selber programmiert.

>dynamischer Abfragenaufbau?
Wenn Du damit meinst, dass wir ständig die Listen ändern, dann ist das nicht so.
Aber wir können, wenn wir es benötigen, zusätzlich Datenfelder in den Listen anzeigen lassen.

Listen ändern? Nein, ich meine die zusätzliche Anzeige anderer Felder, die dynamische Verknüpfung von Daten, so wie ganz oben zitiert ("SQL Verzeichnis", Rechnungsnummer dazu nehmen,..)
Es hat den Anschein, dass die Umsetzung dieses Teils nicht so gut gelungen ist oder die Indizierung zwar vorhanden, aber nicht ausreichend. Wie auch immer, der Tausch der DB bedeutet dann keine Verbesserung.
Man kann an einer solchen Stelle Datawarehouse Produkte und Verfahren einsetzen, wie von Tömmel beschrieben. Das erscheint mir bei der geringen Menge aber wie "Kanonen und Spatzen".

[tömmel]

Ich versteh das Problem, und kann auch Deinen Ausführungen folgen.

Für mich stellen sich zwei Fragen.
1. Würde Microsoft SQL ein schnellere Ergebnis liefern, auch mit Hinsicht, dass wir erst zwei Jahre mit dem
neuen System arbeiten und die Daten mehr werden.

2. Welche Fachfirma kann sich die SQL Abfrage ansehen und ggf. sagen wo ein Index gesetzt werden müßte?

Die Softwarefirma währe sicher für Verbesserungen offen, ich denke ein Zusammenarbeit ggf. auch.

Das know-how müsste eigentlich bei der Herstellerfirma vorhanden sein das Poblem zu lösen - ggf. für bestimmte wichtige Listen eine Lösung zu bieten etc.


Etwas bedenklich finde ich allerdings schon, das da 'schon' (subjektiv oder Objektiv) Geschwindigkeitsprobleme auftreten - .(vielleicht findet der Server die paar Daten im riesen Hauptspeicher garnicht [achtung Scherz]) - an der Hardware liegt's zu 99% nicht (wenn icht wiklich hunderte User drfrauf herumrutschen - die machen aber auch mehr Daten)

Was den 'Umstieg' nach MS angeht - ob und mit welchem Aufwand das geht, wird am Ende auch nur der zuverlässig sagen können, der die Anwendung gebaut hat.

Was tatsächlich eine sinnvolle Lösung ist hängt da von mehreren Faktoren ab -was ist technisch der Königsweg und was ist ökonomisch machbar - wir leben in einer Welt der Kompromisse....


Persönlich würde ich raten nochmal mit dem Hersteller zu sprechen, was er für eine Lösung anbieten kann, damit alle glücklich werden...

[tömmel]

Das erscheint mir bei der geringen Menge aber wie "Kanonen und Spatzen".

Definitiv. Ich kann und will auch nicht sagen, ob die Umsetzung gelungen ist oder die Liste nur strange Ein Index muss ja nebenbei auch zur Nutzung passen - an den Wechsel des dbms glaub ich auch nicht...
Wie gesagt - wenn nicht ein grundsätzliches Problem besteht, denke ich wird am ehesten der Hersteller der Anwendung individuell helfen können. Delphi und Firebird kommen ja auchirgendwie aus dem gleichen Stall, da werden sie schon wissen was sie tun...

[iki]

Kann es denn sein, dass alle optimal programmiert ist und die Listen eben 2-3 sec. brauchen?
Oder ist das in jdem Fall zu langsam?
Oder kann man es nicht sagen?

[defo]

Das kann man schwer beantworten, wenn der Aufbau der Anwendung und das Maß an Reporting Dynamik unbekannt ist.
Es liegt aber wohl auf der Hand, dass eine "beliebige" Abfrageverschachtelung von Anwenderseite nicht immer mit optimaler Indizierung = Performance einhergehen kann. Das ist der Spagat zwischen Freiheitsgrad und Highend Speziallösung.