Adatbázis: SQL, XML DB

ODBC Unicode nem megy

Sziasztok,

 

Volt egy MSSQL DB , egy SQL Expressen. (14.0.3485.1) atmigraltuk egy 15.0.4430.1 es SQL Standard-ra. A DB ossze volt kotve egy MySQL serverrel (Linked Server) ODBC vel. (9.2.0) A MySQL em (8.0.41)

 

Szoval megy minden, auth rendben az mssql bol a mysql be, tudok egyszeru select-et egy table-re, de tarolt eljarast nem tudok meghivni HA a ODBC driverem unicode. Ha ANSI akkor megy.... Nem ertem. SQL -es kollegaval egesz delutan probalkoztunk, jogokat allitottunk, kiprobaltunk mindenfele ODBC verziot, de nem akarja... Sajna ANSI-val elkurodik a kodolas, ezert mindenkepp unicode kell.

 

Nyilvan folos irni, de a regi serveren megy siman unicode al is....

Hogy lehet Oracle Cloud-hoz csatlakozni távolról és adatokat letölteni?

Halihó!

Régóta (kb. 18-20 év) nem használtam Oracle-t. Amikor használtam, akkor valahová fel volt telepítve.

Akkoriban (Oracle 7, 8, 9, 10) az exp paranccsal dumpoltam ki adatbázisból adatokat és schema tartalmakat. Úgy emlékszem, szöveges fájl (SQL script) volt az eredmény, amit fel tudtam darabolni, a schema objektumokat pl. source controlban el tudtam tárolni.

Valami hasonlót szeretnék, de most Oracle 23-ban vannak az adatok, oracle cloud architektúrában. Az ingyenes tier-t használom.

Nem vagyok benne biztos, hogy mi a legjobb irány erre, gyakorlatilag ezt a 2 dolgot akarom: schema objektumokat source controlban, adatokról mentést valahol helyben (saját gépemen) eltárolva.

Mivel hobbi projekten dolgozgatok időnként, előfordult már, hogy az Oracle cloud inaktivitás miatt törölte a teljes adatbázist, vagyis elvesztettem a programot, amit készítettem addig és az adatokat is, amiket kézzel feltöltögettem formokon.

Inaktivitás lesz a jövőben is, viszont el szeretném kerülni az adatbázis tartalmának az elvesztését.

Azt látom, hogy az exp/imp már nem javasolt, van helyette data pump. Olvasgattam, azt látom, hogy ez valami saját formátumot használ. Ez arra biztos jó, hogy lementsem és visszatöltsem a tartalmat, de pl. bináris cuccot source controlba tenni nem túl jó. Azt nem láttam, hogy le tudom-e lokálba tölteni a datapump exportot. Biztonsági mentésnek végül is jó lenne.

Arra gondoltam, hogy majd lokálba feltelepítem az Oracle kliens programokat, hozzákapcsolódok a felhőben lévő adatbázishoz és majd használom a régi módszert. Egyelőre ezzel nem jártam sikerrel, nem tudnak a dolgok kapcsolódni. SQL*Plus-szal és SQLDeveloperrel próbáltam tesztelni, de valami nem ment.

tnsnames.ora-ba bemásoltam a felhős adatbázis weboldalán amit mutatnak. Beállítottam, hogy ACL legyen, saját IP címemet engedélyeztem, beállítottam, hogy nem kötelező a mTLS. Ahogy értem, ha a tűzfalam kiengedi a csomagokat a 1521-es portra, akkor működnie kellene.

Mivel ilyesmi kapcsolódással nem foglalkoztam a régmúltban, fogalmam sincs, hogy mi nem működik, vagy hogy hogyan tesztelhetném.

Enter user-name: skot
Enter password:
ERROR:
ORA-12560: Database communication protocol error.
Help: https://docs.oracle.com/error-help/db/ora-12560/


Enter user-name: admin
Enter password:
ERROR:
ORA-12560: Database communication protocol error.
Help: https://docs.oracle.com/error-help/db/ora-12560/


SP2-0157: unable to CONNECT to ORACLE after 3 attempts, exiting SQL*Plus
Help: https://docs.oracle.com/error-help/db/sp2-0157/

Az ORA-12560 nem mond sokat:

Cause

A lower level communication protocol adapter error occurred.

Action

Do the following:

  • Check for lower level network transport errors in the error stack for additional information.
  • Ensure that the protocol specification used in the address for the connection is correct.
  • For further details, turn on network tracing and rerun the operation. Turn off tracing when the operation is complete.
  • Contact Oracle Support.

Ezekből az elsőt nem tudom, mire gondol. Nem tudom, hol kéne megnézni az error stack-et.

A másodikat másoltam a weboldalról, szóval feltételezem, hogy jó. Ha nem jó, akkor nem tudom, hogy mi a hiba vagy hogyan kéne kijavítani.

A harmadik jól hangzik, de nem tudom, hol  kellene be- és kikapcsolni a network tracking-et.

Tud valaki valami hasznos tanácsot adni? Jó irányba keresgélek, vagy van valami egyszerűbb megoldás ugyanerre, és inkább azt kéne megnéznem?

Altalanos SQL manager

Keresek valami univerzalis SQL managert, ami MSSQL, MySQL, MariaDB, PostgreSQL supportal rendelkezik.

 

Eddig probaltam a DBeaver-t es a HeidiSQL -t de mind a ketto ott hasalt el, hogy nem supportalja MSSQL alatt a user management-et. Van olyan univerzalis manager ami tamogatja ezt?

MariaDB ugyanazon futtatás különböző eredmény

Kedves Fórumtársak!

/usr/bin/mysql  Ver 15.1 Distrib 10.0.37-MariaDB, for Linux (x86_64) using readline 5.1

Adott egy rakás sql parancs-sorozat. Ezek nem érik el a kétszázas darabszámot, egy-egy sorozatban van kb. egy tucat, részben egymásra épülő sql-parancs. Pl. tábla létrehozása, adatbeolvasás csv-file-ból (kB nagyságrendben), táblaszerkezet módosítása és különféle lekérdezések. Ezeket egy PHP szkrip futtatja, mégpedig úgy, hogy minden sorozatból futtatja az elsőt, majd mindegyikből a másodikat és így tovább. Elvégez különféle ellenőrzéseket (ide értve, hogy egyáltalán lefut-e a parancs), az eredményeket meg kiírja két táblába. Mindez egyugyanazon adatbázisban.

Azt tapasztaltam, de reprodukálható módon nem teszteltem, hogy újrafuttatás esetén nem feltétlenül ugyanazon eredmények születtek, esetenként a kapott eredmény képtelenségnek látszott. Pl. a php-script azt találta, hogy két select esetében a két eredménylistában különböző számú oszlop van, holott a két select-et egyedileg futtatva a két eredménylista teljesen azonos. Ismételt futtatás után meg egyformának találta (ahogy elvárná az ember két egyforma eredménylista esetében).

Egyetlen script egyenként csinálja a futtatást. És igen, nem bizonyított a program helyessége, de korábban ilyen furcsaságokat nem tapasztaltam.

Lehetséges, hogy a táblák létrehozása, importálás, szerkezetmódosítás végrehajtása fáziskésésben van, és a lekérdezések nem a (végleges) adattartalmon hajtódnak végre? Vagy valami más lehetőség?

Köszi, üdvrivalgással:
KEA.

Postgres tanfolyamot keresek

Sziasztok!

 

Jövő évre szeretnék a fejlesztő kollégáimnak egy teljesítményorientált postgres tanfolyamot. Klaszter építés meg indexek használata gyakorlati példákon keresztül, hogy lássák mennyit hoz a konyhára.

2-3 napos időkeretben.

Tudtok ajánlani ilyet?

 

köszi!

Tajszám tagolása SQLite-ban

Szervusztok!

Kezdő adatbázis-bütykölő vagyok, az SQLite-tal birkózom. Ő áll nyerésre.

A tajszámokkal gyűlik meg most a bajom, amik ügye 0-val is kezdődhetnek, így csak azt a lehetőséget találtam, hogy text adattípusban tároljam őket. Namost szeretném elérni, hogy hármasával tagolódjanak a lekérdezésben, mert úgy jobban olvasható.

Van ehhez valamilyen pöpec lekérdezés, ami a formátumot is előírja a SQLite-nak, vagy mivel úgysem fogok vele műveleteket végezni, vigyem inkább úgy be? Bár el tudok olyan szitut képzelni, hogy valaki folyamatosan írva akar keresni.

Vagy eleve rossz adattípussal kezdtem?

Remélem érthetően írtam.

mongoexport Atlassal

Sziasztok!

 

mongoexport-tal próbálnék egy db-t kiexportálni Yettel mobilnetről MongoDB Atlasból (Free tier). Felületről kimásoltam a parancsot, ahogy írta de csak várakozik a végtelenségig, nem csinál semmit. A DNS tuti szar mert a Yettel DNS szervere nem adja vissza a clusterem TXT rekordját, a google-é meg igen. Próbáltam Telekomos mobilnetről is, ott legalább a DNS jó de az eredmény ugyanaz.

 

$ mongoexport -vvvvvvvv --uri "mongodb+srv://<USER>:<PASS>@vitcluster0.7xu0lb3.mongodb.net/versenyek?authSource=admin&replicaSet=atlas-hzuuzv-shard-0" --collection verseny --out verseny.json --pretty
2024-08-16T16:23:43.616+0200    will listen for SIGTERM, SIGINT, and SIGKILL
2024-08-16T16:24:25.975+0200    error dialing ac-7fnfgxj-shard-00-00.7xu0lb3.mongodb.net:27017: dial tcp: lookup ac-7fnfgxj-shard-00-00.7xu0lb3.mongodb.net: no such host
2024-08-16T16:26:26.916+0200	error dialing ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net:27017: dial tcp: lookup ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net: no such host
2024-08-16T16:28:28.088+0200	error dialing ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net:27017: dial tcp: lookup ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net: no such host
2024-08-16T16:29:28.206+0200	error dialing ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net:27017: dial tcp: lookup ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net: no such host
2024-08-16T16:32:33.369+0200	error dialing ac-7fnfgxj-shard-00-02.7xu0lb3.mongodb.net:27017: dial tcp: lookup ac-7fnfgxj-shard-00-02.7xu0lb3.mongodb.net: no such host
2024-08-16T16:33:34.103+0200	error dialing ac-7fnfgxj-shard-00-02.7xu0lb3.mongodb.net:27017: dial tcp: lookup ac-7fnfgxj-shard-00-02.7xu0lb3.mongodb.net: no such host
2024-08-16T16:34:34.374+0200	error dialing ac-7fnfgxj-shard-00-02.7xu0lb3.mongodb.net:27017: dial tcp: lookup ac-7fnfgxj-shard-00-02.7xu0lb3.mongodb.net: no such host




$ dig vitcluster0.7xu0lb3.mongodb.net ANY

; <<>> DiG 9.18.28-0ubuntu0.20.04.1-Ubuntu <<>> vitcluster0.7xu0lb3.mongodb.net ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9928
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;vitcluster0.7xu0lb3.mongodb.net. IN    ANY

;; ANSWER SECTION:
vitcluster0.7xu0lb3.mongodb.net. 60 IN    TXT    "authSource=admin&replicaSet=atlas-hzuuzv-shard-0"

;; Query time: 103 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (TCP)
;; WHEN: Fri Aug 16 16:29:39 CEST 2024
;; MSG SIZE  rcvd: 121

 

Namármost, hogy ebből hogy a bánatba találja ki, hogy az ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net-hez akar kapcsolódni, azt nem tudom de eltalálja mert a cluster címek stimmelnek.

 

$ dig ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net

; <<>> DiG 9.18.28-0ubuntu0.20.04.1-Ubuntu <<>> ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6237
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net. IN A

;; ANSWER SECTION:
ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net. 55 IN CNAME    mtm-aws-eucentral1-0-m0-12-shard-00-01.mr4xo.mongodb.net.
mtm-aws-eucentral1-0-m0-12-shard-00-01.mr4xo.mongodb.net. 55 IN    CNAME ec2-18-185-253-138.eu-central-1.compute.amazonaws.com.
ec2-18-185-253-138.eu-central-1.compute.amazonaws.com. 7195 IN A 18.185.253.138

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Aug 16 16:39:50 CEST 2024
;; MSG SIZE  rcvd: 213
 

Próbáltam úgy is, hogy a cluster primary node-jához direktben csatlakozom +srv nélkül, de az se járt sikerrel.

pentike@T440s:~/sandbox$ mongoexport -vvvvvvvv --uri "mongodb://<USER>:<PASS>@ac-7fnfgxj-shard-00-01.7xu0lb3.mongodb.net:27017/versenyek?authSource=admin&replicaSet=atlas-hzuuzv-shard-0" --collection verseny --out verseny.json --pretty
2024-08-16T16:38:44.628+0200    will listen for SIGTERM, SIGINT, and SIGKILL
^C2024-08-16T16:41:05.570+0200    signal 'interrupt' received; forcefully terminating
pentike@T440s:~/sandbox$ mongoexport -vvvvvvvv --uri "mongodb://<USER>:<PASS>@18.185.253.138:27017/versenyek?authSource=admin&replicaSet=atlas-hzuuzv-shard-0" --collection verseny --out verseny.json --pretty
2024-08-16T16:41:32.221+0200    will listen for SIGTERM, SIGINT, and SIGKILL
^C2024-08-16T16:43:19.650+0200    signal 'interrupt' received; forcefully terminating

 

Mit rontok el?

PSQL remote link

hi,

 

Van 1 gép, ami GCP-ben van és egy másik, ami kishazánk egyik hosting szolgáltatójánál. A két gép között ha pl. scp-vel nézem, jó minőségű kapcsolatot látok, azaz nagy sávszélességet és alacsony latency-t.

Szeretnék a két gép között SQL kapcsolatottal üzemeltetni vmit (egy weboldal egyébkétn).

 

A probléma, hogy lassú, de irgalmatlanul, pl. select * egy táblára helyben 0.2 sec távolra pedig 1.2 - 2 sec. Miért, hogy lehetne ezen tuningolni? Az általam olvasott fórumok és szakirodalom szerint messze nem szabadna, hogy ennyit számítson. De lehet, hogy rosszat olvastam.

 

Update:

Most épp "viszonylag' gyors, azaz kb. 2x olyan gyors volt, mint amit nap közben mértem. Nem tudom, minek tudható be, egyelőre annak tulajdonítom, hogy este van. Holnap napközben megnézem újra. Ha valóban ez befolyásolja ennyire, akkor nyílván nem lesz élhető így a szolgáltatás. Bár az az igazság, hogy ez még mindig harmatos így összességében, ha ilyen is maradna örökre.

 

update:

Időszűke miatt ebbol valószínűleg jelenleg nem lesz semmi, más vonalon megyünk megoldás irányába.