Adatbázis: SQL, XML DB

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.

Lehet, hogy nem jól keresek, de nem találok megoldást egy egyszerű lekérdezésre, hogy miért nem az történik, amit várok. Nem dob hibát, csak nem hajtja végre!

Tehát egy CASE-WHEN-ELSE kifejezésben miért nem tudok szöveget hozzáfűzni az eredményhez akkor, ha valamilyen műveletet is végzek rajta?

Példa adatok: SQLite Editor (sqlitetutorial.net)
Lekérdezés: 
SELECT Name ,
        (
    CASE
    WHEN Milliseconds < 300000 THEN
    'Rövid'
    ELSE Milliseconds/1000 || ':'
    END ) AS 'Seconds'
FROM tracks;

Azt várnám, hogy hozzáfűzi a kettőspontot, de nem történik meg. Ha nem végzek műveletet a kiolvasott értéken, akkor viszont összefűzi. Hogyan tudnám ezt megvalósítani egyszerűen? 

Optimizing the databases at Quora - Engineering at Quora https://t.co/vNnhGswPQi #mysql

— Peter Zaitsev (@PeterZaitsev) June 17, 2023

Link: https://quoraengineering.quora.com/Optimizing-the-databases-at-Quora

Egy mariaDb 10.1.48 szerver root jelszavát szeretném módosítani, de semmilyen leírt módon nem sikerül.

A dokumentáció szerinti

ALTER USER 'root'@'localhost' IDENTIFIED BY 'newpassword';

parancsot visszadobja a következő hibaüzenettel:

ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'USER 'root'@'localhost' IDENTIFIED BY 'newpassword'' at line 1

Ha a mysql.user táblában írom felül a password mező értékét, az is hatástalan. Továbbra is jelszó nélkül engedi a hozzáférést. Próbáltam a mysqld_safe-et is, --skip-grant-tables paraméterrel, de ez sem segített.

Mi a megfelelő módja a root password beállításának MariaDb alatt?

MySql (MariaDb) verzióváltás után ütköztem a következő problémába.

Egy int mezőt egy subselect segítségével töltök fel: mezo=(SELECT SUM(masikMezo) FROM ...)

A régi verzión ez rendben lefutott, de az új verzióban, ha egyetlen sor sem fele meg a subselect feltételének, úgy 0 helyett NULL értéket ad vissza. A NULL azonban nem tárolható a mezőben, csak 0. Az is lehet, hogy eddig is NULL-t adott vissza, de azt automatán 0-ra konvertálta.

A kérdés: hogyan tudom a NULL értékeket 0-ra konvertálni, hogy az UPDATE az új verzión is hibamentesen lefuthasson. Van valamilyen konfigurációs paramétere a MariaDb-nek, amit ez eléri? Vagy a subselectet lehetne picit módosítani, hogy NULL esetén 0 legyen?

Sziasztok

Adott egy szerveren egy régi Sentry 9.1.2 telepítés, snap store-ból, külön postgres DB-vel. 
Ezt el kellene költöztetnem az új self-hosted dockeres rendszerbe egy új szerverre. Régi szerveren pg_dumpall-al kiexportáltam a DB-t, majd az új szerverre a régi 9.1.2-est próbáltam életre kelteni. 
psql -U postgres < backup.sql parancsot próbáltam, látszólag be is megy minden, viszont amint utána indítok egy docker-compose up-ot, vagy nem bír elindulni, mert a db-ben nem talál meg dolgokat. Ha migrationt vagy a ./install.sh-t futtatom le, akkor pedig tisztán indul, mintha be sem importáltam volna.
Ilyet csinált már valaki? Mit ronthatok el?

Helló!

Database history tables upgraded:  No

Találtam egy double.sql fájlt, ami talán ezt lenne hivatott megvalósítani, de:

postgres@tarthost:/home/rattila$ psql zabbix <zabbix-install/zabbix-DB-Postgresql-double.sql 
ERROR:  type of inherited column "value_min" must be changed in child tables too
ERROR:  type of inherited column "value" must be changed in child tables too
postgres@tarthost:/home/rattila$

Messze nem értek az adatbázishoz, így kellene a segítség, hogy hogyan lehetne megszüntetni ezt a hibát.
A tábla definíciója:

                                     Table "public.history"
 Column |     Type      | Collation | Nullable | Default | Storage | Stats target | Description 
--------+---------------+-----------+----------+---------+---------+--------------+-------------
 itemid | bigint        |           | not null |         | plain   |              | 
 clock  | integer       |           | not null | 0       | plain   |              | 
 value  | numeric(16,4) |           | not null | 0.0000  | main    |              | 
 ns     | integer       |           | not null | 0       | plain   |              | 
Indexes:
    "history_1" btree (itemid, clock)
Triggers:
    partition_trg BEFORE INSERT ON history FOR EACH ROW EXECUTE FUNCTION trg_partition('day')
Child tables: partitions.history_p2017_11_04,
              partitions.history_p2017_11_05,
              partitions.history_p2017_11_06,
              partitions.history_p2017_11_07,
              partitions.history_p2017_11_08,
              ....sok-sok partíció...
 

Egyébként hogyan lehetne megszabadulni ezektől a régi adatoktól?Bőven elég lenne az idei, esetleg a 2022-es
(léván idén elég keveset futott a Zabbix, mert csak nem rég sikerült visszakalapálnom dec. 25.-ei lebetegedéséből)

Köszönöm!

Sziasztok!

root@tarthost:~# pg_lsclusters 
Ver Cluster Port Status                Owner    Data directory               Log file
9.3 main    5434 down,binaries_missing postgres /var/lib/postgresql/9.3/main /var/log/postgresql/postgresql-9.3-main.log
9.5 main    5432 down,binaries_missing postgres /var/lib/postgresql/9.5/main /var/log/postgresql/postgresql-9.5-main.log
10  main    5433 online                postgres /var/lib/postgresql/10/main  /var/log/postgresql/postgresql-10-main.log
12  main    5435 down                  postgres /var/lib/postgresql/12/main  /var/log/postgresql/postgresql-12-main.log
 

Jelenleg a 10-es verzióval fut, de a TimeScaleDB-hez nem találtam deb csomagokat és mindent a 12-höz akart lehozni, amit
meg is csináltam.

Van valami egyszerű módszer, amivel  a 10-esből a 12-esbe tudnám átvinni a teljes Zabbix DB-t?

A DB jelenelg 69GB, a PG partíció 591GB.

Köszönettel:
Ruzsi