ODBC Treiber forced install ?

M

Mabsterone

Neuer Benutzer
Beiträge
2
Hallo,

ich nutze MariaDB in der aktuellen Version.

Es gibt eine Datenbank in einem Projekt, ca. 7,5 Millionen Einträge.
Hier werden regelmässig on demand ca 600k neue Einträge gepusht und etwa ebensoviele gelöscht werden.

Es kann aber auf dem PrimaryKey zu Doubletten kommen, deswegen benutze ich:
INSERT IGNORE, habe aber auch ON DUPLICATE KEY, WHERE NOT EXISTS etc. ausprobiert.

Aktuell die performanteste Variante ist ein INSERT IGNORE der einen Value-Block mit ca. 100 Datensätzen gleichzeitig beeinhaltet.
Benutzt wird hier VB6 Anwendungen, ich möchte nun mit mehreren unterschiedlichen ODBC Treibern Performance Tests durchführen.

Die benötigten 32-bit Treiber der Version 2.0.xxx bis 3.1.17 hole ich mir direkt von der webpage von mariaDB.

Nun finde ich den msi Installer etwas unglücklich konzipiert.... er lässt mich immer nur einen Treiber installieren und dort die Priorität auf dem neusten (im Vergleich zum derzeit installierten Triber)

Ich kann 2.0.0.0 mit 2.0.0.9 überschreiben, aber nicht umgekehrt, dann wirft der Installer mich einfach raus und macht nichts.

Da ich relativ viel teste, möchte ich eigentlich nur die Werte im .open ändern... "DBVerbindung.Open ("Provider=MSDASQL;DRIVER={MariaDB ODBC 3.1 Driver}...." um zumindest unter den Hauptversionen wechseln zu können ohne jedesmal den Treiber zu entfernen, einen neuen zu installieren und den Rechner neu zu starten.

Hierzu würde ich gerne 3 Treiber (2.0.xx, 3.0.x.x und 3.1.x.x) parallel installieren.
Kennt jemand eine Möglichkeit (so eine Art "forced") beim installieren per .msi oder eine sinnvolle Alternative ?

Vielen Dank im voraus für Eure Hilfe,

MfG...Marc
 
Zuletzt bearbeitet:
Werbung:
Mabsterone schrieb:
Es kann aber auf dem PrimaryKey zu Doubletten kommen, deswegen benutze ich:
Zum Vergrößern anklicken....
Dann machst Du prinzipiell was falsch. Warum nutzt Du nicht sowas wie:

Code: 
postgres=# create table mabsterone(id int generated always as identity primary key, data text);
CREATE TABLE
postgres=# insert into mabsterone (data) values ('foo');
INSERT 0 1
postgres=# insert into mabsterone (data) values ('bar');
INSERT 0 1
postgres=# insert into mabsterone (data) values ('batz');
INSERT 0 1
postgres=# insert into mabsterone (id, data) values (10, 'peng!');
ERROR:  cannot insert a non-DEFAULT value into column "id"
DETAIL:  Column "id" is an identity column defined as GENERATED ALWAYS.
HINT:  Use OVERRIDING SYSTEM VALUE to override.
postgres=#

Da verhindert die DB von selber schon den dummen Versuch, für die ID einen Wert vorzugeben - selbst wenn er frei wäre.
 
akretschmer schrieb:
Dann machst Du prinzipiell was falsch. Warum nutzt Du nicht sowas wie:
Zum Vergrößern anklicken....

Ich denke es braucht noch etwas nehr Hintergrundinfo.

Meine Datenquelle(600k) neu zu schreibende Datensätze kommen aus mehreren Datenbanken von unterschiedlichen Servern.
Diese sind teilweise redundant, fällt einer aus werden die Daten auf einem anderen geschrieben.
Somit kann es vorkommen, das 2 exakt gleiche Datensätze vorliegen auf unterschiedlichen Servern, ich benutzt keine transaktions-taugliche Datenbank.

Den PrimaryKey bilde ich aus 3 (nicht unique) Feldern, ein Zeitstempel, eine Eigentümerkennung, und eine Vorgangsnummer.

In regelmässigen Zyklus werden die (Puffer-) Server geleert und es wird ein Datensatz erzeugt und in die Hauptdatenbank hinzugefügt.
Hier dürfen Datensätze aber nicht doppelt sein. Deswegen der Primary key und das INSERT IGNORE INTO, so fange ich sicher jede Doublette ab.

Bis dahin funktioniert das auch einwandfrei und performant, ich habe aber eher zufällig rausgefunden das ODBC 3.1.xx deutlich (ca. 40%) schneller performt als 2.0.xx. Nun wollte ich das mal mit allen Varianten austesten um eine Performance Analyse zu haben, ob eine Migration des ODBC Treibers auf eine neuere Version eventuell Sinn macht und suche einen Weg mehrere ODBC Treiber parallel auf meinem System zu nutzen.
 
Wenn Du die Inhalte kennst, die der ODBC Manager benötigt, damit er die ODBC Treiber anzeigt, kannst Du es vielleicht über die Registry / Scripting machen.
Hier gibt es Infos zu ODBC
learn.microsoft.com

Registry Entries for ODBC Components - ODBC API Reference

Registry Entries for ODBC Components
learn.microsoft.com

Es gibt auch Webseiten, die das für spezielle Treiber beschreiben. Die könnte man als Anleitung nehmen. Wenn Du das ans Laufen bekommst, bleibt allerdings die Frage, ob die Tests dann aussagekräftig sind.
 
Werbung:
Mabsterone schrieb:
Meine Datenquelle(600k) neu zu schreibende Datensätze kommen aus mehreren Datenbanken von unterschiedlichen Servern.
Diese sind teilweise redundant, fällt einer aus werden die Daten auf einem anderen geschrieben.
Somit kann es vorkommen, das 2 exakt gleiche Datensätze vorliegen auf unterschiedlichen Servern, ich benutzt keine transaktions-taugliche Datenbank.
Zum Vergrößern anklicken....
Das ist alles kein Problem - wenn man denn es richtig macht. Wir haben ein Produkt, das nennt sich BDR bzw. neuerdings PGD. BDR steht für BiDirectional Replication, PGD für PostGresql Distributed. Egal, welchen Namen man verwendet, intern ist es so, daß u.a. exakt diese Pobleme bekannt und gelöst sind. Das funktioniert, egal ob MultiMaster zwischen zwei RZ 200 Meter oder 20.000km auseinander sind. Technologie ist da - man muß sie nur noch einsetzen.

Und ja: wenn Du keine transaktions-taugliche DB verwendest: erhoffst Du Dir jetzt Mitleid, oder was genau?
 
Zurück
Oben