Ist es möglich, Tibero anstelle von Oracle zu verwenden? Und ist es notwendig

In diesem Artikel werde ich Ihnen erzählen, wie ich ernsthaft über eine Alternative zu Oracle nachgedacht habe. Aber was ist mit Postgre, sagst du? Ja, aber es gibt Nuancen. Zuerst beschäftigen wir uns mit der Frage "Warum Oracle?"
Geschäftslogik in unserer Datenbank. In dem Oracle-Buch für Profis schreibt Tom Kite
Bei der Entwicklung von Datenbankanwendungen verwende ich ein sehr einfaches Mantra:

Wenn möglich, machen Sie es mit einer einzelnen SQL-Anweisung.
Wenn dies nicht mit einer einzelnen SQL-Anweisung möglich ist, führen Sie dies in PL / SQL aus.
Wenn dies in PL / SQL nicht möglich ist, versuchen Sie es mit einer gespeicherten Java-Prozedur.
Wenn dies in Java nicht möglich ist, tun Sie dies als externe Prozedur in C;
Wenn dies nicht als externes Verfahren in C implementiert werden kann, müssen Sie ernsthaft darüber nachdenken, warum dies überhaupt geschieht ...
und beim Systemdesign folge ich dieser Regel. Objekttypen in Oracle sind besonders erfreulich: Mit ihrer Hilfe wird komplexe Geschäftslogik gemäß allen Kanonen von OOP wunderschön und bequem implementiert.

Oracle ist teuer. Es zu kaufen und nicht alles zu verwenden, was darin enthalten ist, wird ein Fehler sein.
Dabei gibt es immer einen Faktor für Team und Kompetenzen. Wenn Ihr Team seit zehn Jahren alles bei Oracle entwickelt, kann die Veröffentlichung von Postgre schmerzhaft sein.

Oracle ist teuer. Es ist ein Fehler, so teuer, dass Sie mehrmals darüber schreiben können und nicht an die Notwendigkeit von Oracle in einem neuen Projekt denken.

Ich bin bereits mehrmals auf Veröffentlichungen über das koreanische Tibero-Produkt gestoßen, das angeblich als Ersatz für Oracle entwickelt wurde. Und jetzt haben sie eine Anziehungskraft von beispielloser Großzügigkeit - Standardlizenzen werden für Entwickler fast kostenlos verteilt, für einen Dollar für einen Socket. Wir verstehen also: Was die Koreaner im Moment anbieten können. Mit Autos haben sie es doch schon (fast) geschafft!

Versuchsbeschreibung


Vertreter von TMaxSoft sagen, dass Tibero fast zu 100% mit Oracle kompatibel ist und es ein Dienstprogramm für die Datenbankmigration gibt. Ich beschloss, meine Produktbasis mit Geschäftslogik in Oracle zu nutzen und den Charme von OOP in PL \ SQL zu nutzen und auf Tibero zu übertragen. In dieser Veröffentlichung wird die Migration der Daten selbst nicht berücksichtigt, sie ist weniger interessant und ich habe noch keine vollständige Migration versucht.

Die Aufgabe ist folgende:

1. Tabellen übertragen.
2. Übertragung von Indizes, Schlüsseln usw.
3. Übertragen Sie Pakete und Trigger.
4. Übertragung von Objekttypen.

Aber zuerst beschäftigen wir uns mit den Werkzeugen.

Die Werkzeuge


Google weiß wenig über Tibero. Wir haben die Datenbank selbst in Form einer virtuellen Maschine heruntergeladen, auf der bereits alles bereitgestellt wurde. Es gibt nur zwei Tools: ein Dienstprogramm zum Migrieren von T-UP und eine IDE für DBA und den tbAdmin-Entwickler. Alles wird in Java gemacht, läuft theoretisch überall.

T-UP sieht ungefähr so ​​aus:


Hauptfenster: Datenbankverbindungen.


Wenn Sie auf Optionen klicken, können Sie etwas konfigurieren.


Am wichtigsten ist, dass Sie die zu migrierenden Objekttypen auswählen können.

Es konnten keine Anweisungen, Hilfe oder Tipps gefunden werden.
Es macht den Eindruck eines hausgemachten Dienstprogramms. Manchmal flog sie mit Hinrichtungen aus, aber im Grunde arbeitete sie nach Bedarf.

Das zweite Tool ist die Tibero Admin IDE. Es kann von der TMaxSoft-Website heruntergeladen werden, wenn Sie sich dort zuerst registrieren. Dort können Sie auch eine Demo-Lizenz erwerben.


Tibero Admin sieht aus wie eine typische alte IDE

Ich bin an das hervorragende PL / SQL-Entwicklertool von Allround Automations gewöhnt. Vergessen Sie in Tibero Admin die kontextbezogenen Eingabeaufforderungen. Nach dem Klicken auf den „Punkt“ wird nichts auf Ihrem Bildschirm angezeigt. Die Namen von Tabellen und Objekten werden nicht an Sie angehängt. Geben Sie einfach den Code ein, Sie Programmierer. Hilfe, Dokumentation? Nein. Es gibt eine Dokumentation zum DBMS auf der Website des Herstellers, eine so interessante ... ohne Suche. Für die IDE wurde keine Dokumentation gefunden. Es gibt jedoch nichts Kompliziertes. Es gab Probleme mit der Autorisierung - es stellte sich heraus, dass dem Benutzer DBA-Rechte erteilt werden müssen, um einfach in tbAdmin zu gelangen. Und interessant bei den Ports ist 8630 für SYS, für alle anderen 8629 .

IDE-Fehler. Von Zeit zu Zeit, wenn Sie irgendwo stochern, fliegt der Nachrichtenindex außerhalb der Grenzen heraus , eine Nachricht wie java.lang.Exception: Engagement erfolgreich ist sehr beängstigend. Es ist notwendig, verschiedene Arten von SQL- und PSM-Fenstern zu berücksichtigen: Im ersten Fall ist es unwahrscheinlich, dass Sie Programmcode kompilieren, im zweiten Fall führen Sie die Anforderung nicht aus. Nach PL / SQL Developer - ein miserabler Anschein einer linken Hand ...

Zum Experiment kommen.

Tabellenmigration


Wir wählen das Schema in T-UP aus, klicken auf Migrieren, wählen zuerst die "Tabellen" in den Optionen aus und der Übertragungsprozess beginnt. Ich bin auf zwei Probleme gestoßen.

TISCHPLÄTZE. Ich habe beschlossen, sie in Tabellen zu übertragen, aber Tibero scheint versucht zu haben, so viel Speicherplatz für sie zu reservieren, wie sie in der Quellendatenbank belegen. Und das ist viel, und er konnte nicht. Ich habe die Tabellenbereiche manuell erstellt, und dann ging alles gut.

Zusätzlich zu Tabellen mit DEFAULT-Datumswerten vom Typ '31 .12.2019 '. In den Oracle-Einstellungen haben wir dieses Format registriert, für Tibero hilft es
alter session set nls_date_format='DD.MM.YYYY'; 
Aber T-UP kann das nirgendwo tun. Kollegen von TMaxSoft haben empfohlen, die Variable TB_NLS_DATE_FORMAT = "DD.MM.YYYY" festzulegen, aber es hat mir persönlich nicht geholfen. Vielleicht habe ich etwas falsch gemacht. Ich musste Tabellen mit solchen Parametern manuell erstellen, es gibt nicht viele davon.

Ergebnis des ersten Schritts: Das Verschieben der Tabellenstruktur von Oracle nach Tibero funktioniert gut.

Schlüssel und Indizes.


Wir aktivieren die Kontrollkästchen INDEX, CONSTRAINT in T-UP und Forward. Probleme mit CHECK traten aufgrund der gleichen Situation mit dem Datum auf. Im Allgemeinen wurden Indizes, Primärschlüssel und Prüfungen erstellt. Aber ich konnte keine Fremdschlüssel in der frisch erstellten Datenbank finden. Die Migration von Konstanten endet im T-UP-Protokoll mit der Meldung "Migration fehlgeschlagen: java.lang.NullPointerException". Zufall? Ich glaube nicht…

Pakete und Trigger.


Bei Triggern habe ich nichts kompliziertes, sie wurden perfekt erstellt. Es stimmt, ich habe nicht überprüft, wie sie funktionieren, dies wird eine separate Geschichte sein.

Lassen Sie uns über Prozeduren und Funktionen sprechen, die einen Teil der Logik implementieren. Hier lief leider nicht alles perfekt.

Einfach gesagt: In der Armee von Tibero gibt es kein Wort NEU . Das Konstrukt o: = NEW t_my_type () wird nicht kompiliert. In Oracle ist es wahr, nicht obligatorisch, aber ich habe immer aus irgendeinem Grund geschrieben. Ich musste löschen.

Mit der DBA-Rolle kann SQL Window auf alle Tabellen zugreifen. Wenn Sie jedoch ein Paket oder eine Prozedur in einem Schema mit einer solchen Rolle kompilieren und Tabellen und Objekte eines anderen Schemas verwenden, müssen Sie dem Objekt die entsprechende Berechtigung erteilen. Die Magie der DBA-Rolle hilft hier nicht weiter.

Aus dem spezifischen. Ich habe ein seltsames FORALL in meiner Datenbank, das jedoch funktioniert.

 --     PROCEDURE save_tar_test AS TYPE number_table IS TABLE OF NUMBER INDEX BY BINARY_INTEGER; TYPE date_table IS TABLE OF DATE INDEX BY BINARY_INTEGER; TYPE varchar50_table IS TABLE OF VARCHAR2(50) INDEX BY BINARY_INTEGER; TYPE char1_table IS TABLE OF CHAR(1) INDEX BY BINARY_INTEGER; TYPE t_tar_det_out_upd_rec_test IS RECORD ( --   cmr_tar_det_id number_table, in_stamp date_table, err_code_id number_table ); tdou_rec t_tar_det_out_upd_rec_test; BEGIN --   ,  tdou_rec  :      Oracle FORALL j IN 1 .. tdou_rec.cmr_tar_det_id.COUNT UPDATE cmr_tar_det dd SET err_code_id = tdou_rec.err_code_id(j) WHERE dd.cmr_tar_det_id = tdou_rec.cmr_tar_det_id(j) AND in_stamp = tdou_rec.in_stamp(j); END; 

Tibero sagt, "dml-Anweisung muss den Bulk-In-Parameter ia forall close haben" . Und ich verstehe es tief im Inneren, aber dieser Code musste in einem regelmäßigen Zyklus wiederholt werden.

Die Situation mit Tabellen, die Objekte enthalten, ist schlimmer.

 CREATE OR REPLACE TYPE S1.TYPE_PAY_HIST AS OBJECT ( pay_status_id NUMBER(1), stamp DATE ); CREATE OR REPLACE TYPE S1.TABLE_PAY_HIST AS VARRAY(10) OF type_pay_hist; create table S2.RECEIPT ( receipt_id NUMBER(8) not null, pay_sum NUMBER(12,2) not null, receipt_hist S1.TABLE_PAY_HIST ); FUNCTION receipt_status_change(p_cmr_receipt_id NUMBER, p_new_status NUMBER) RETURN NUMBER AS l_receipt_hist s1.table_pay_hist; l_type_pay_hist s1.type_pay_hist; l_status NUMBER; BEGIN BEGIN SELECT receipt_hist INTO l_receipt_hist FROM receipt p WHERE p.receipt_id = p_cmr_receipt_id FOR UPDATE; EXCEPTION WHEN NO_DATA_FOUND THEN RETURN c_err_not_find_status; END; ... END; 

Wir haben einen Kompilierungsfehler, geben Sie mistmatch ein.

Die Jungs von TMaxSoft haben diese Version des Codes vorgeschlagen:

 create or replace FUNCTION .... AS l_receipt_hist table_pay_hist; l_type_pay_hist type_pay_hist; l_status NUMBER; cmr_receipt_row cmr_receipt%rowtype; BEGIN BEGIN SELECT * INTO cmr_receipt_row FROM cmr_receipt p WHERE p.cmr_receipt_id = p_cmr_receipt_id FOR UPDATE; SELECT TYPE_PAY_HIST(r.pay_status_id,r.stamp) bulk collect INTO l_receipt_hist FROM cmr_receipt p,table(p.receipt_hist) r WHERE p.cmr_receipt_id = p_cmr_receipt_id; EXCEPTION WHEN NO_DATA_FOUND THEN dbms_output.put_line('NO_DATA_FOUND'); RETURN null;--c_err_not_find_status; END; ... END; 

Arbeit es funktioniert wahrscheinlich. Aber nicht so bequem, und Sie müssen den Code wiederholen.

Der Rest wird normal kompiliert, mit Ausnahme bestimmter Dinge wie SDO_GEOM. Tibero hat übrigens ein Analogon. Seine Hände hatten sein Arbeitszimmer noch nicht erreicht.

Typen


In einem der Projekte nutzen wir die Leistung von OOP by Oracle Hollow.
Die aufregendste Frage für Tibero war diesbezüglich.

Wir erstellen einen bestimmten Typ, der für eine Reihe anderer Typen grundlegend ist.

 CREATE OR REPLACE TYPE t_tar_object AS OBJECT ( id NUMBER(12), smth NUMBER(12), CONSTRUCTOR FUNCTION t_tar_object RETURN SELF AS RESULT, MEMBER FUNCTION target(param IN NUMBER DEFAULT NULL) RETURN NUMBER, MEMBER FUNCTION inside(o t_tar_object) RETURN NUMBER, MEMBER FUNCTION clone RETURN t_tar_object ) NOT FINAL; --  CREATE OR REPLACE TYPE BODY t_tar_object AS CONSTRUCTOR FUNCTION t_tar_object RETURN SELF AS RESULT AS BEGIN RETURN; END; MEMBER FUNCTION target(param IN NUMBER DEFAULT NULL) RETURN NUMBER AS BEGIN RETURN id; END; MEMBER FUNCTION clone RETURN t_tar_object AS BEGIN RETURN NULL ; END; END; 

Und jetzt versuchen wir, einen würdigen Erben für ihn zu schaffen.

 CREATE OR REPLACE TYPE t_tar_service UNDER t_tar_object ( is_virtual NUMBER(1), CONSTRUCTOR FUNCTION t_tar_service (p_serv_obj t_tar_object, p_main_id NUMBER, p_pack_id NUMBER) RETURN SELF AS RESULT, OVERRIDING MEMBER FUNCTION target(param IN NUMBER DEFAULT NULL) RETURN NUMBER, OVERRIDING MEMBER FUNCTION clone RETURN t_tar_object ) NOT FINAL; 

Der Compiler weigert sich, die Zielfunktion zu überschreiben. Es gibt jedoch keine Fragen zur Klonfunktion. Es stellte sich heraus, dass Tibero OVERRIDING nicht mochte, wenn die Methode Parameter hat. Okay, entfernen Sie das Wort OVERRIDING. Aber das ist alarmierend und wir schreiben Testskripte. Bisher mit dem übergeordneten Typ.

 declare o1 t_tar_object; i1 number := 100; begin o1 := t_tar_object; o1.id := 1; i1 := o1.target; -- dbms_output.put_line (i1)   . --      ,  ,     i1   -- if i1 > 0 then dbms_output.put_line ('big'); end if; if i1 < 0 then dbms_output.put_line ('small'); end if; if i1 = 0 then dbms_output.put_line ('zero'); end if; if i1 is null then dbms_output.put_line ('null'); end if; end; 

Es scheint, dass wir dem Programm keine Wahl überlassen haben, egal welchen Wert die Variable i1 annimmt, etwas sollte in der Ausgabe erscheinen. Aber ... nichts erscheint!


Ich erinnerte mich sofort an einen großartigen Film

Diese Kuriosität endet nicht dort. Das Experiment noch schlimmer machen

 declare o1 t_tar_object; i1 number := 100; begin o1 := t_tar_object; o1.id := 1; i1 := o1.target; --  ,      -    i1 := 2; if i1 > 0 then dbms_output.put_line ('big'); end if; if i1 < 0 then dbms_output.put_line ('small'); end if; if i1 = 0 then dbms_output.put_line ('zero'); end if; if i1 is null then dbms_output.put_line ('null'); end if; end; 

Selbst die Tatsache, dass wir nach all den Manipulationen mit den Methoden des Objekts den Wert der Variablen starr festlegen, ändert nichts - die Ausgabe ist leer.

Kontrollexperiment, testen Sie sich auf Wahnsinn:

 declare o1 t_tar_object; i1 number ; begin o1 := t_tar_object; o1.id := 1; --i1 := o1.target;    i1 := 2; if i1 > 0 then dbms_output.put_line ('big'); end if; if i1 < 0 then dbms_output.put_line ('small'); end if; if i1 = 0 then dbms_output.put_line ('zero'); end if; if i1 is null then dbms_output.put_line ('null'); end if; end; 

Das geschätzte "große" erscheint in der Ausgabe. Gruselig, nicht wahr? Mithilfe eines wissenschaftlichen Stochers haben die Mitarbeiter von TMaxSoft herausgefunden, dass sich das Objekt entsprechend verhält, wenn Sie die Nuance „NOT FINAL“ aus der t_tar_object-Spezifikation entfernen. Aber warum brauchen wir dann so einen ... ohne Erben?

Es macht keinen Sinn, weiter über OOP in Tibero zu sprechen. Wie in der Tat die OOP in Tibero. Danach stellt sich eine andere Frage: und der Code der Prozeduren und Funktionen, die kompiliert wurden - funktioniert es richtig? Ich weiss noch nicht. Eine große Menge Code ist eingewandert und kompiliert. Für ein Projekt, das die oben genannten Arten von Übungen nicht enthält, ist dies ein definitiver Erfolg. Das Testen der korrekten Ausführung von Code ist jedoch eine ernsthafte Aufgabe. Und um ehrlich zu sein, hatte ich nicht erwartet, sie zu treffen. Ich werde nicht bereit sein zu sagen, ob ich ein Projekt auf diesem DBMS haben werde. Wenn dies jedoch der Fall ist, erfolgt die Entwicklung unter Oracle unter Verwendung normaler praktischer Tools und mit regelmäßiger Migration zu Tibero. Das Schreiben von Code in der IDE ohne kontextbezogene Eingabeaufforderungen und mit periodischen Fehlern der Schnittstelle selbst ist ein unterdurchschnittliches Vergnügen.

Schlussfolgerungen


Hat Tibero in seinem gegenwärtigen Zustand eine Zukunft? Nicht sicher. Wenn Sie sich die Kosten für Lizenzen ohne Megascale ansehen, kostet ein Standard-Socket ungefähr 800.000. Das ist billiger als Oracle, aber manchmal nicht. Und da ich aus eigener Erfahrung überzeugt war, ist dies bisher noch nicht einmal in der Nähe von Oracle.

Ist es sinnvoll, den fast kostenlosen Tibero zu verwenden, der jetzt angeboten wird? Vielleicht ja. Sie sagen, dass es bei der Bezahlung der Kosten für technischen Support (99.000 Rubel pro Jahr für eine Steckdose) erlaubt ist, diese Basis in kommerziellen Projekten zu verwenden. Wenn Sie ein Team von Orakelisten zur Verfügung haben und etwas erstellen und auf Ihrem Server platzieren möchten, das nicht zu schwierig, aber billiger und schneller ist - eine interessante Option. Sie können immer noch die Sanktionskarte spielen und problematischen Kunden mitteilen, dass Korea nicht die Vereinigten Staaten sind.

Soll ich vorhandene Projekte von Oracle nach Tibero übersetzen? Auf keinen Fall. Es gibt keinen Grund, ein solches Abenteuer zu suchen. Es ist einfacher, den technischen Support von Oracle aufzugeben und niemandem etwas zu zahlen.

Und wenn Sie eine neue Instanz eines alten Projekts erstellen müssen, das unter Oracle ausgeführt wird? Und als Ergebnis neue Lizenzen kaufen? Denken Sie hier darüber nach. Es ist möglich, dass Ihre Basis migriert und qualitativ funktioniert. Aber denken Sie sofort daran, zwei Bereiche im Projekt zu unterstützen, oder übersetzen Sie alles in Tibero. Wir berücksichtigen Arbeitskosten, Risiken und Vorteile billigerer Lizenzen. Vergleichen, entscheiden.

Vielleicht wird in der nächsten Version von Tibero alles anders sein. Es ist nur erforderlich, die Typen fertigzustellen, eine normale IDE zu erstellen und möglicherweise die Preispolitik zu ändern. Und wenn das DBMS das gleiche ist wie bei Autos, können Koreaner nach 5 Jahren einen bedeutenden Marktanteil einnehmen und den Hegemon ersetzen. Wir werden sehen.

PS


Ein ernstes Plus bei der Auswahl eines DBMS für ein neues Projekt kann die Arbeit des technischen Supports von TMaxSoft sein. Ich habe nicht einmal eine Lizenz für einen Dollar gekauft und die Jungs haben mir sehr schnell und deutlich interessiert geantwortet. Sie halfen sowohl bei dummen als auch bei den hier beschriebenen Fragen. Das Feedback ist hervorragend.

Source: https://habr.com/ru/post/de413147/


All Articles