Adatbázis: SQL, XML DB

Üdv,

Tudtok ajánlani PgSQL-hez free admin tool-t Windows alá? A default pgadmin4 nem akar elindulni. /Régen működött...:(/

The pgAdmin 4 server could not be contacted:

...

PermissionError: [WinError 32] A folyamat nem f�r hozz� a f�jlhoz, mert azt egy m�sik folyamat haszn�lja:

'C:\\Users\\admin\\AppData\\Roaming\\pgAdmin\\pgadmin4.db' -> 'C:\\Users\\admin\\AppData\\Roaming\\pgAdmin\\pgadmin4.db.20240406095008'

Nem fogja semmi (elvileg), mi fogná? :o Reboot után is ugyanez a hiba.

Itt próbálok nézelődni: https://www.postgresql.org/download/products/1-administrationdevelopmen…

https://hup.hu/comment/3032071#comment-3032071 adta az ötletet, hogy vitassuk meg, 2024-ben hogy áll a helyzet a Relációs-NoSQL fronton. Pár szempontot feldobok nyitónak:

- mit tekintünk sémának?

- teljesítmény? Írás, olvasás.

- hibatűrés?

- mennyire bonyolult, mennyire könnyű adminisztrálni?

Szerk:

Elírtam a topic nyitót, mert nem relációs-nosql háborút akartam indítani, hanem olyan példákat látni, hogy mi van akkor ha valamit _meg lehet csinálni_ két vagy több adatbázisban akkor mi az a pont ahol már érdemes bevállalni a heterogén környezetből eredő hátrányokat. Ez lehet akár két nosql adatbázis is, nem csak relációs-nosql vonalon lehet gondolkozni.

Sziasztok,

Adott egy DB, amit egy .NET programmal ernek el (a programban van egy service user beallitva). eddig local SQL userrel ment, de szeretnenk helyette domain usert hasznalni. Viszont ha jol ertelmezem, ket opcio van csak:

1. local userrel, a connection stringben meghatarozva.

2. domain userrel, de akkor az auth "pass through", tehat az appot futtato user accountal auth-ol be.

Van arra esetleg megoldas, hogy a kodban meghatarozott domain userrel is mukodjon a dolog?

Kedves tapasztalt fórumtársak!

A jelenség lecsupasztíva:

Adott egy tábla és benne sorok

create table T1 ( ID serial, primary key (ID) ) engine=InnoDB;
insert into T1 values
(1),(2),(3),(5);

Feladat: listázandók az ID-k, melléjük pedig a következő létezi ID érték (mint NextID), valamint a kettő különbsége (mint delta):

select b.ID,
               a.ID as NextID,
               a.ID - b.ID as delta
          from (select * from T1) as a,
               (select * from T1) as b
         where a.ID in (select min(ID)
                          from T1
                         where ID > b.ID
                       )
;

Elvárásszerűen működik. Probléma akkor van, ha allekérdezésbe teszem, és az eredménylistát szűrném az egynél nagyobb delta értékekre:

select *
  from (select b.ID,
               a.ID as NextID,
               a.ID - b.ID as delta
          from (select * from T1) as a,
               (select * from T1) as b
         where a.ID in (select min(ID)
                          from T1
                         where ID > b.ID
                       )
       ) as c
 where delta > 1;

Erre azt feleli, hogy ERROR 1690 (22003): BIGINT UNSIGNED value is out of range. Miért?

Köszi:
KEA.

Sziasztok!

 Olyan Oracle DBA tanfolyam érdekelne, ahol jól megérthetek alapvető dolgokat. Oracle adatbázisszerverek menedzseléséhez szeretnék kb. ilyen képességeket magabiztosan elsajátítani:

-Adatbázisok létrehozása, a várható trehelés szerinti beállítása, migrálása, menedzselése.

-Jól funkcionáló mentések konfigurálása, visszaállítása, stb. (pl. Veeam környezetben).

-Az adatbázisok monitorozása, ez alapján a szükséges beavatkozások (esetleg proaktív) elvégzése.

-Az Oracle adatbázisszerverek alapvető koncepciójának mély megértése, stb.

 Tudtok ajánlani ilyeneket? Angol nyelven és/vagy távoktatásban is megfelel, ha nincs más. Előre is köszönöm.

Sziasztok!

Szeretnék Windows Server-ről ODBC-n Firebird adatbázishoz csatlakozni connectionstringgel, de az alábbi hibaüzenetet kapom:

Error: ADO NET Source has failed to acquire the connection {1DB3A0F7-7859-481D-9145-9D46FC323FE3} with the following error message: "ERROR [08004] [ODBC Firebird Driver]Unable to connect to data source: library 'gds32.dll' failed to load
ERROR [01S00] [ODBC Firebird Driver]Invalid connection string attribute
ERROR [01S00] [ODBC Firebird Driver]Invalid connection string attribute
ERROR [01S00] [ODBC Firebird Driver]Invalid connection string attribute
ERROR [01S00] [ODBC Firebird Driver]Invalid connection string attribute
ERROR [01S00] [ODBC Firebird Driver]Invalid connection string attribute
ERROR [01S00] [ODBC Firebird Driver]Invalid connection string attribute
ERROR [01S00] [ODBC Firebird Driver]Invalid connection string attribute".
 

Próbáltam ODBC DSN-t létrehozni, nem sikerült. Telepítettem a 32 bites és a 64 bites klienst, hiába. Lehúztam külön a DLL-t, de azt megadva crashel az ODBC. Valakinek van valami útmutatója? Google-t már kiolvastam, de nem igazán segített. 

Update: Megoldódott. Nem elég a klienst telepíteni, a Firebird 5.0 telepítőjét elindítva, csak a kliens programokat telepítve jön egy lépés, ami legenerálja a dll-eket a SYSWOW64 és system32 folderekbe, így már működik. 

A minap felmerült a kér(d)és, hogy jó lenne Oracle adatbázisból "belátni" egy MS-SQL-be közvetlenül, nem pedig  scriptekkel, ODBC-n pakolgatni fájlokon keresztül az adatokat.

Scenario egyszerűnek tűnt: Linux-ről odbc működik, adott user belát az MSSQL-be, megy a lekérdezés, scriptelve szépen be lehet tölteni adatokat.

Linux még CentOS7, rajta friss unixODBC-2.3.11-1.rh.x86_64 illetve msodbcsql17-17.10.5.1-1.x86_64 is helyet foglal, ODBC-n mindenből szépen elérhető a DSN=SQLSRV1 kiszolgáló, de a DB-link nem akarja az igazságot: tcpdumppal látszik, hogy még oda sem fordul az SQL-serverhez.

Itt tartok:

#hs/admin/initDEMMO.ora
HS_FDS_CONNECT_INFO = SQLSRV1
HS_FDS_TRACE_LEVEL = Debug
HS_FDS_SHAREABLE_NAME = /usr/lib64/libodbc.so

#network/admin/tnsnames.ora - részlet

DEMMO =
    ( DESCRIPTION =
        ( ADDRESS = ( PROTOCOL = TCP )
            ( HOST = orcl.local)
            ( PORT = 1545 )
        )
        ( CONNECT_DATA =
            ( SID = DEMMO )
        )
        ( HS = OK )
    )

#network/admin/listener.ora - részlet

DEMMO =
      (ADDRESS = (PROTOCOL = TCP)(HOST = orcl.local)(PORT = 1545))

SID_LIST_DEMMO =
  (SID_LIST =
    (SID_DESC=
      (SID_NAME=DEMMO)
      (ORACLE_HOME=/opt/oracle/product/19.3.0/)
      (PROGRAM=dg4odbc)
        (ENVS=LD_LIBRARY_PATH="/usr/lib64:/opt/oracle/product/19.3.0/lib/")

    )
 )

A DBlink a create database link SQLSRV1 connect to "mssqluser" identified by "mssqluserpass" using 'DEMMO'; készült.

Kérdés,hogy mit rontottam el/mit néztem be?

Tűzfal kifelé nincs, selinux permissive módban, a 1545-ös port szabad.

https://kepkuldes.com/images/68bae2876c2d3bcda9a80b535443df19.png

Ezek vannak az adatbázisban, de nincs jogosultsága a felhasználómnak törölni. a CPanelről lépek be a phpmyadminba. A CPanel fájlkezelője mutatja a rejtett fájlokat, azok közül kellene kitöröljek valamit adminként?

Az installation.php fájt kellett kitöröljem, már telepłthettem így az újat.

Adott a következő probléma:

Teszt környezetet szeretnék felállítani és az éles környezetből szednék hozzá adatokat. Viszont mivel nincs szükség a teljes adatbázisra (2,5 TB), a táblák pedig évenkénti filegroup-okban csücsülnek, ezért azt találtam ki, hogy ezeket a filegroup-okat állítanám vissza.

Backup így néz ki:

BACKUP DATABASE MyDB

    FILEGROUP = 'MyDB_2022'  

    TO URL = 'https://<Azure Blob Container .bck fájl>'  

    WITH CREDENTIAL = '<CREDENTIAL>'  

    ,COMPRESSION;  

A restore pedig így:

RESTORE DATABASE MyDB

   FILEGROUP = 'MyDB_2022'

FROM URL = 'https://<Azure Blob Container .bck fájl>'

    WITH CREDENTIAL = '<CREDENTIAL>', NORECOVERY, PARTIAL, REPLACE,

        MOVE 'MyDB_2022' TO 'X:\MyDB_2022.ndf'

Sorban backup-ot készítek az Azure Blob Container-be a PRIMARY-ről, a 2022-es, majd a 2023-as filegroupokról. 

Aztán restore-nál NORECOVERY-vel visszaállítom a PRIMARY mdf-et, illetve a logot, majd a 2022-es és a 2023-as filegroup-ot.

Az utolsó két parancs már hibára fut, a RESTORE MyDB WITH RECOVERY sikeresen lefut és online az adatbázis. Viszont néhány tábla lekérdezésekor az alábbi hibát kapom:

Could not continue scan with NOLOCK due to data movement.

Tehát corrupt lesz az adatbázis. Csinált már ilyet valaki esetleg és meg tudja mondani, hogy mit csinálok rosszul? 

Sziasztok!

A táblák külön .ibd fájlokban vannak, de a /var/lib/mysql/ibdata1 fájl ennek ellenére napi 90 GB-ot nő. Mi a túrótól lehet ez?
Debian 12, innodb minden tábla, a teljes adatbázisméret 45 GB. Van pár olyan tábla, amiben gyakori a módosítás és van olyan is, amibe gyakori az írás és utána a perceken belüli törlés, de nem tudom mi indokol az adatbázis méretéhez képest kétszeres növekedést naponta. Ekkora index nincs...
ib_logfile0 mérete 100 MB.

Hogyan tudom egyáltalán megnézni, hogy mi milyen arányban van ebben a fájlban?

Előre is köszönök minden ötletet.