Von 21 GB nach 4,3 GB verkleinern der samples-Tabelle, das kann man erfolgreich nennen.
Da hat sich ein intensiveres Beschäftigen mit der MariaDB schon gelohnt.
Wie viele Rows waren vorher und sind jetzt noch in der samples-Tabelle drin?
Tabelle samples (4,3 GB) enthält jetzt 32.097.395 Datensätze.
Wie viele es vorher waren, keine Ahnung. Habe ich leider nicht notiert.
Es wäre gut, wenn Du Deinen SQL-Code in ein Code-Fenster einfügen könntest.
Dann kann man den SQL-Code besser lesen.
Ich habe mich heute drüber gemacht, die Tabelle samples zu verkleinern.
Ich bin so vorgegangen, wie hier schon mal erwähnt:
- p4d-backup.sh ausgeführt
- Tabelle samples gelöscht
- Tabelle samples neu erstellt
- samples-Backup importiert
Die Datenbankdatei samples.ibd ist jetzt nur noch 4,3 GB groß, vorher waren es 21 GB.
Zur Sicherheit habe ich natürlich zusätzliche Vorarbeit geleistet.
Man weiß ja nie, ob was schief geht.
- Snapshot-Sicherung des Proxmox p4d LXC-Container
- Datenbank beendet und alle p4 Datenbank-Files gesichert
Hier nochmal die Zusammenfassung der eigentlichen Tabellen-Neuerstellungs-Aktion:
#
# Linux
#
# Dienst p4d – stoppen | automatischer Start dauerhaft deaktivieren | Status anzeigen
sudo systemctl stop p4d.service
sudo systemctl disable p4d.service
sudo systemctl status p4d.service
# Anmelden an Datenbank p4
mysql -u p4 -pp4 p4#
# MariaDB
#
# Tabellen anzeigen
SHOW TABLES;
# Tabelle samples löschen
DROP TABLE IF EXISTS samples;
# Tabellen anzeigen
SHOW TABLES;
# Tabelle samples erstellen
CREATE TABLE `samples` (
`address` int(4) unsigned NOT NULL,
`type` varchar(8) NOT NULL,
`aggregate` varchar(1) NOT NULL,
`time` datetime NOT NULL,
`inssp` int(10) DEFAULT NULL,
`updsp` int(10) DEFAULT NULL,
`value` float(14,2) DEFAULT NULL,
`text` varchar(50) DEFAULT NULL,
`samples` int(3) DEFAULT NULL,
PRIMARY KEY (`address`,`type`,`aggregate`,`time`),
KEY `idxtime` (`time`),
KEY `idxtype` (`type`),
KEY `idxaggregate` (`aggregate`),
KEY `idxaddr_type_time` (`address`,`type`,`time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;
# Tabellen anzeigen
SHOW TABLES;#
# Linux
#
# Zum Backup-Ordner
cd /mnt/nas8/p4dbackup
ls -lh
# Backup der Tabelle samples unzippen
sudo gunzip samples-dump.sql.gz
# Restore der Tabelle samples
sudo mysql -u p4 -pp4 -Dp4 < samples-dump.sql
# Dienst p4d – starten | automatischer Start dauerhaft aktivieren | Status anzeigen
sudo systemctl start p4d.service
sudo systemctl enable p4d.service
sudo systemctl status p4d.serviceWenn du HA hast, benötigst du noch einen RS232-Converter und ein Nullmodemkabel.
Danke.
Also muss HA die Daten auch auf einer seriellen Verbindung empfangen.
Wie die p4d-Software von horchi.
ich würde die Methode OPTIMIZE TABLE samples; bevorzugen. Vorher natürlich den p4d-Dienst beenden und die Daten sichern.
Info habe ich mir angeschaut.
Folgende Problematik sehe ich da.
QuoteOPTIMIZE TABLE samples;
Dieser Befehl reorganisiert den physischen Speicher der Tabelle und ihrer Indizes.
Bei InnoDB-Tabellen wird im Hintergrund eine neue, kompakte Datei erstellt und die alte danach gelöscht.
Dann muss ich vor OPTIMIZE TABLE samples; die Partition noch größer machen.
Genau das wollte ich vermeiden.
Ich wollte ja erreichen, nach der Aktion mehr freien Plattenplatz zu haben ohne die Partiton zu vergrößern.
Was spricht gegen Tabelle löschen, Tabelle neu erstellen und Restore des Backups?
Hallo,
gibt es eine Anleitung, welche Voraussetzungen für die Anbindung der Lambdatronic 3200 an HA notwendig sind?
Hallo,
Aggregate läuft nun wie es soll.
Es werden täglich alle Daten älter als 365 Tage aggregiert.
Dadurch sind nun die Daten in der Tabelle samples massiv geschrumpft.
Die Tabelle samples enthält nur noch 13 GB Daten.
Die Datenbankdatei samples.ibd ist aber 21 GB groß.
Deshalb wollte ich die Datenbankdatei samples.ibd verkleinern.
Hat das schon mal jemand gemacht und kann dazu was sagen?
Ich vermute, das geht vermutlich am Besten so:
- Tabelle samples löschen
- Tabelle samples neu erstellen
- Backup samples importieren
Hier habe ich mal notiert, wie ich es machen würde.
Kann da bitte mal jemand drüberschauen, ob das so passen kann oder ob ich was vergessen habe.
#
# Linux
#
# Dienst p4d – stoppen
sudo systemctl stop p4d.service
# Anmelden an Datenbank p4
mysql -u p4 -pp4 p4--
-- MariaDB
--
-- Tabellen anzeigen
SHOW TABLES;
-- Tabelle samples löschen
DROP TABLE IF EXISTS samples;
-- Tabellen anzeigen
SHOW TABLES;
-- Tabelle samples erstellen
CREATE TABLE `samples` (
`address` int(4) unsigned NOT NULL,
`type` varchar(8) NOT NULL,
`aggregate` varchar(1) NOT NULL,
`time` datetime NOT NULL,
`inssp` int(10) DEFAULT NULL,
`updsp` int(10) DEFAULT NULL,
`value` float(14,2) DEFAULT NULL,
`text` varchar(50) DEFAULT NULL,
`samples` int(3) DEFAULT NULL,
PRIMARY KEY (`address`,`type`,`aggregate`,`time`),
KEY `idxtime` (`time`),
KEY `idxtype` (`type`),
KEY `idxaggregate` (`aggregate`),
KEY `idxaddr_type_time` (`address`,`type`,`time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;
-- Tabellen anzeigen
SHOW TABLES;#
# Linux
#
# Backup der Tabelle samples unzippen
sudo gunzip samples-dump.sql.gz
# Backup der Tabelle samples importieren
sudo mysql -u p4 -pp4 -Dp4 < samples-dump.sql
# Dienst p4d – starten
sudo systemctl start p4d.serviceDisplay MoreLaut dem unten verlinkten Tutorial müssen Sie möglicherweise die Bindungsadresse für MariaDB ändern, damit diese auf Remote-IPs zugreifen kann.
Versuchen Sie, die Bindungsadresse von 127.0.0.1 auf 0.0.0.0 zu ändern.
Diese befindet sich möglicherweise in:
/etc/mysql/my.cnf
oder:
/etc/mysql/mariadb.conf.d/50-server.cnf
Perfekt! 
Bist Du Amerikaner oder ausgewandert?
Du darfst hier auch duzen und musst nicht siezen, falls Dir der Unterschied bekannt ist.
Hallo,
ich wollte mit DBeaver remote auf die p4-Datenbank zugreifen.
Das funktioniert leider nicht.
Fehler bei Test Connection:
Socket fail to connect to 192.168.23.85. Connection refused: getsockopt
Connection refused: getsockoptFehler bei Anmeldung:
Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
Connect timed outWelche Einstellung ist noch notwendig für einen Remote-Zugriff auf die p4-Datenbank?
Folgendes hab ich bisher gemacht:
In der MariaDB einen zweiten Benutzer angelegt:
CREATE USER 'p4dremote'@'%' IDENTIFIED BY 'Pa55w0rd';
GRANT ALL PRIVILEGES ON p4.* TO 'p4dremote'@'%' IDENTIFIED BY 'Pa55w0rd';
flush privileges;
exitIn DBeaver eine neue Verbindung erstellt:
Server: 192.168.23.85
Port: 3306
Database: p4
User: p4dremote
Am p4d-Server sind folgende Ports offen:
$ sudo netstat -tnpl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 222/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1/init
tcp 0 0 0.0.0.0:1111 0.0.0.0:* LISTEN 396/p4d
tcp 0 0 127.0.0.54:53 0.0.0.0:* LISTEN 222/systemd-resolve
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 353/mariadbd
tcp 0 0 127.0.0.1:1883 0.0.0.0:* LISTEN 276/mosquitto
tcp6 0 0 ::1:1883 :::* LISTEN 276/mosquitto
tcp6 0 0 :::22 :::* LISTEN 1/init
ich finde es echt super, wie du dich in eine (vermutlich) vorher unbekannte Thematik reinwühlst!
Danke, aber so ganz unbekannt ist mir SQL nicht. 
Übrigens hat Jürgen SolarEngel in seiner sehr gut gemachten Erläuterung ebenfalls auf den 15-Minuten-Offset verzichtet. Andernfalls wären in seiner selektierten Teilmenge ebenfalls die ersten 15 Minuten nicht aggregiert worden.
Wäre es mein Projekt, dann würde ich das SQL-Script entsprechend abändern (und dadurch vereinfachen), auch wenn das "Problem" normalerweise nur bei den allerersten Daten in der Tabelle samples auftritt (oder eben in selektierten Teilmengen).
Solange sich horchi nicht dazu äußert, warum er die 15 Minuten eingebaut hat, können wir nur mutmaßen.
Ansonsten könnte man auch einen Pull request stellen:
Und noch ein (etwas kleinlicher) Hinweis:
Dein erster manueller Versuch der Aggregierung für "2020-09-09 12:00:00 bis 18:00:00" hat zwar (teilweise) "A"-Sätze erzeugt, diese waren aber nicht aggregiert, sondern nur dupliziert. Das betrifft zwar nur 6 Stunden, aber ich hätte diese Daten ebenfalls (korrekt) zusammengefasst haben wollen (vielleicht hast du ja auch schon darüber nachgedacht)?
Doch, auch diese Zeiten passen jetzt.
Das war ja der erste Versuch.
Und zu dem Zeitpunkt wurde noch auf Sekunden und nicht auf Minuten aggregiert.
Da kannte ich den Faktor 60 (Sekunden zu Minuten umrechnen) noch nicht.
Die Daten habe ich wieder gelöscht. 
Aber gut aufgepasst. 
MariaDB [p4]> select * from samples
-> where address = 4 and type = "VA"
-> and time > "2020-09-09 12:00:00"
-> and time < "2020-09-09 18:00:00"
-> order by time asc;
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
| address | type | aggregate | time | inssp | updsp | value | text | samples |
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
| 4 | VA | A | 2020-09-09 12:30:00 | 1777915230 | 1777915230 | 18.00 | NULL | 10 |
| 4 | VA | A | 2020-09-09 12:45:00 | 1777915230 | 1777915230 | 18.00 | NULL | 10 |
| 4 | VA | A | 2020-09-09 13:00:00 | 1777915230 | 1777915230 | 18.50 | NULL | 10 |
| 4 | VA | A | 2020-09-09 13:15:00 | 1777915230 | 1777915230 | 18.60 | NULL | 10 |
| 4 | VA | A | 2020-09-09 13:30:00 | 1777915230 | 1777915230 | 19.00 | NULL | 10 |
| 4 | VA | A | 2020-09-09 13:45:00 | 1777915230 | 1777915230 | 19.30 | NULL | 10 |
| 4 | VA | A | 2020-09-09 14:00:00 | 1777915230 | 1777915230 | 19.75 | NULL | 10 |
| 4 | VA | A | 2020-09-09 14:15:00 | 1777915230 | 1777915230 | 20.25 | NULL | 10 |
| 4 | VA | A | 2020-09-09 14:30:00 | 1777915230 | 1777915230 | 20.70 | NULL | 10 |
| 4 | VA | A | 2020-09-09 14:45:00 | 1777915230 | 1777915230 | 21.00 | NULL | 10 |
| 4 | VA | A | 2020-09-09 15:00:00 | 1777915230 | 1777915230 | 21.45 | NULL | 10 |
| 4 | VA | A | 2020-09-09 15:15:00 | 1777915230 | 1777915230 | 21.70 | NULL | 10 |
| 4 | VA | A | 2020-09-09 15:30:00 | 1777915230 | 1777915230 | 22.00 | NULL | 10 |
| 4 | VA | A | 2020-09-09 15:45:00 | 1777915230 | 1777915230 | 22.20 | NULL | 10 |
| 4 | VA | A | 2020-09-09 16:00:00 | 1777915230 | 1777915230 | 22.50 | NULL | 10 |
| 4 | VA | A | 2020-09-09 16:15:00 | 1777915230 | 1777915230 | 22.50 | NULL | 10 |
| 4 | VA | A | 2020-09-09 16:30:00 | 1777915230 | 1777915230 | 22.50 | NULL | 10 |
| 4 | VA | A | 2020-09-09 16:45:00 | 1777915230 | 1777915230 | 22.30 | NULL | 10 |
| 4 | VA | A | 2020-09-09 17:00:00 | 1777915230 | 1777915230 | 22.00 | NULL | 10 |
| 4 | VA | A | 2020-09-09 17:15:00 | 1777915230 | 1777915230 | 21.60 | NULL | 10 |
| 4 | VA | A | 2020-09-09 17:30:00 | 1777915230 | 1777915230 | 21.50 | NULL | 10 |
| 4 | VA | A | 2020-09-09 17:45:00 | 1777915230 | 1777915230 | 21.50 | NULL | 10 |
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
22 rows in set (0,007 sec)Für mich ist es eh' unlogisch, das "Aggregate Intervall" per Parameter einstellen zu können, der dazu passenden Offset jedoch fest hinterlegt ist (+ INTERVAL 15 MINUTE). Bei anderen Einstellungen als 15 Minuten bzw. 900 Sekunden, führt das zu unschönen Nebeneffekten.
Warum dieser Offset von 15 Minuten überhaupt eingeführt wurde ist mir auch unklar.
Das habe ich auch noch nicht verstanden, warum der Offset 15 Minuten ist und für was er gebraucht wird.
Display Morewenn das Aggregation-Bereinigung-script manuell aufrufst z.B. mit den zwei Parametern Datum(2021-01-01) und Zeitintervall(900)
z.B ./aggregate-samples-manual.sh 2021-01-01 900
das funktioniert auch und aggregiert in 15 Minuten-Zeitintervallen. (900 sind die 15Minuten in 900Sekunden umgerechnet).
Dann brauchst im Original-script (aggregate-samples-manual.sh) nix ändern.
Ja, OK, so funktioniert es natürlich auch.
Aber der Intervall wird ja in Minuten und nicht Sekunden angegeben. Zumindest in der GUI ist das so.
Ich habe im Skript /usr/local/bin/aggregate-samples-manual.sh nichts angepasst.
Ich habe das SQL-Statement manuell ausgeführt.
Jetzt ist der Parameter "Historie [Tage]" = 1200 gesetzt.
Mal sehen, was heute Nacht passiert.
Es müssten morgen Aggregate-Werte bis Ende 2022/Anfang 2023 vorhanden sein.
Heute sind alten Werte bis Anfang Januar 2023 als Aggregate-Werte vorhanden.
Aggregate automatisch über Nacht funktioniert also immer noch.
Danke erst Mal für Eure Unterstützung und Denkanstöße.
Ich habe jetzt folgendes gemacht.
Das erste halbe Jahr time < "2021-01-01" habe ich manuell mit meiner angepassten Syntax bearbeitet.
Das hat funktioniert.
Dann hat aber über Nacht p4d automatisch begonnen, alle Daten von 2021-01-01 bis Mai 2025 (Mai 2026 minus 365 Tage) mit Aggregate zu bearbeiten.
Damit lief aber meine Partition voll und Aggregate ist abgebrochen.
Das MYSQL-Datenbankfile samples.ibd ist sehr groß geworden.
Danach habe ich die neuen Aggregate-Werte alle wieder gelöscht.
delete from samples
where aggregate = 'A'
and time >= "2021-01-01";Dann die Partition um 2 GB vergrößert
Dann den Parameter "Historie [Tage]" = 1500 gesetzt.
Am nächsten Tag waren alle alten Werte bis Anfang 2022 als Aggregate-Werte vorhanden.
Das hat also schon mal funktioniert.
Jetzt ist der Parameter "Historie [Tage]" = 1200 gesetzt.
Mal sehen, was heute Nacht passiert.
Es müssten morgen Aggregate-Werte bis Ende 2022/Anfang 2023 vorhanden sein.
In meinem Aggregationsskript (/usr/local/bin/aggregate-samples-manual.sh) ist der Wert 15 nicht fest einprogrammiert (hard-coded); es handelt sich um eine Variable, die an das Skript übergeben wird.
Bei mir steht im Skript /usr/local/bin/aggregate-samples-manual.sh natürlich auch die Variable ${INT} drin.
Aber wie oben geschrieben, erfolgt damit Aggregate auf 15 Sekunden und nicht 15 Minuten.
Es fehlt der Faktor 60
-- Original SELECT-Syntax aus dem Skript (Mit Fehler, weil Aggregate auf 15 Sekunden)
replace into samples
select address, type, 'A' as aggregate,
CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV ${INT}) * ${INT})) + INTERVAL 15 MINUTE time,
unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,
round(sum(value)/count(*), 2) as value, text, count(*) samples
from
samples
where
aggregate != 'A' and time <= '${DATE}'
group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV ${INT}) * ${INT})) + INTERVAL 15 MINUTE, address, type;-- Angepasste SELECT-Syntax auf Aggregate auf 15 Minuten
replace into samples
select address, type, 'A' as aggregate,
CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV (${INT} * 60)) * (${INT} * 60))) + INTERVAL 15 MINUTE time,
unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,
round(sum(value)/count(*), 2) as value, text, count(*) samples
from
samples
where
aggregate != 'A' and time <= '${DATE}'
group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV (${INT} * 60)) * (${INT} * 60))) + INTERVAL 15 MINUTE, address, type;Kann ich nicht, weil meine Daten noch nicht älter als 365 Tage sind.
OK, schade.
Vll. meldet sich ja noch jemand anderes.
Ich würde es gerne verifizieren, bevor ich das von mir auf 15 Minuten Aggregate angepasste Skript /usr/local/bin/aggregate-samples-manual.sh loslaufen lasse.
Mein p4d läuft jetzt 6 Jahre und ich habe festgestellt, dass noch kein einziger Datensatz mit Aggregate bearbeitet wurde.
Kannst Du mir mal bitte ein paar ältere Daten zeigen, bei denen Aggregate bereits lief.
Gerne von der Außentemperatur.
Hier das SQL-Statement dazu, Datum ggf. anpassen:
select * from samples
where address = 4 and type = "VA"
and time > "2024-10-09 12:00:00"
and time < "2024-10-09 18:00:00"
order by time asc;Ich habe vermutlich den Fehler im Skript /usr/local/bin/aggregate-samples-manual.sh gefunden.
Das Skript fasst die Datensätze alle 15 Sekunden zusammen und nicht alle 15 Minuten.
Es fehlt die Umrechnung von Sekunden auf Minuten (x 60).
SELECT-Syntax aus dem Skript (Mit Fehler, weil Aggregate 15 Sekunden):
select address, type, 'A' as aggregate,
CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 15) * 15)) + INTERVAL 15 MINUTE time,
unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,
round(sum(value)/count(*), 2) as value, text, count(*) samples
from samples
where aggregate != 'A'
and time > "2020-10-09 12:00:00"
and time < "2020-10-09 18:00:00"
and address = 4 and type = "VA"
group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 15) * 15)) + INTERVAL 15 MINUTE, address, type;SELECT-Syntax angepasst auf Aggregate 15 Minuten:
select address, type, 'A' as aggregate,
CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV (15 * 60)) * (15 * 60))) + INTERVAL 15 MINUTE time,
unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,
round(sum(value)/count(*), 2) as value, text, count(*) samples
from samples
where aggregate != 'A'
and time > "2020-10-09 12:00:00"
and time < "2020-10-09 18:00:00"
and address = 4 and type = "VA"
group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV (15 * 60)) * (15 * 60))) + INTERVAL 15 MINUTE, address, type;Es gibt aber unter "/usr/local/bin" auch ein Skript "aggregate-samples-manual.sh", welches die gleiche Funktionalität beinhaltet. Das könntest Du nutzen.
Ich habe mir das Skript /usr/local/bin/aggregate-samples-manual.sh angeschaut.
Die SQL-Statements darin habe ich erst mal direkt in der Datenbank ausgeführt.
Und auch nur für Daten älter als 01.01.2021. p4d läuft bei mir seit ca. Juli 2020.
Also hätte es ca. 6 Monate betroffen.
Aber es kam ein Fehler, weil die Partition zu klein war und die MariaDB keinen Platz hatte, um tmp-Daten zu erstellen.
Also wurde die Partition vergrößert, jetzt sind 6 GB frei.
Nun habe ich den Zeitbereich erst mal verkleinert auf 6 Stunden von 09.09.2020 12:00 Uhr bis 09.09.2020 18:00 Uhr
time > "2020-09-09 12:00:00"
time < "2020-09-09 18:00:00"
Hier vorab mein Fazit:
Die Aggregate-Funktion in der Datei /usr/local/bin/aggregate-samples-manual.sh scheint nicht zu funktionieren.
Ausführliche Beschreibung ab hier.
Das Ergebnis aller SQL-Statements ist zusätzlich in der separaten Datei "p4d_Aggregate_samples_Ergebnis.sql" zu sehen.
Es wurden folgende SQL-Statement ausgeführt.
1. SQL-Statement
Vor Aggregate ermitteln, wie viele Datensätze der Außentemperatur für den Zeitraum vorhanden sind.
Ergebnis sind 240 Datensätze Außentemperatur.
select * from samples
where address = 4 and type = "VA"
and time > "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"
order by time asc;
240 rows in set (0,005 sec)2. SQL-Statement
Datensätze für Aggregate ermitteln und mit aggregate='A' markieren.
replace into samples
select address, type, 'A' as aggregate,
CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 15) * 15)) + INTERVAL 15 MINUTE time,
unix_timestamp(sysdate()) as inssp, unix_timestamp(sysdate()) as updsp,
round(sum(value)/count(*), 2) as value, text, count(*) samples
from samples
where aggregate != 'A'
and time > "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"
group by CONCAT(DATE(time), ' ', SEC_TO_TIME((TIME_TO_SEC(time) DIV 15) * 15)) + INTERVAL 15 MINUTE, address, type;
Query OK, 11040 rows affected (0,705 sec)
Records: 11040 Duplicates: 0 Warnings: 03. SQL-Statement
Nach dem Markieren der Datensätze für Aggregate ermitteln, wie viele Datensätze der Außentemperatur für den Zeitraum vorhanden sind.
Ergebnis sind plötzlich 470 Datensätze Außentemperatur.
select * from samples
where address = 4 and type = "VA"
and time > "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"
order by time asc;
470 rows in set (0,005 sec)4. SQL-Statement
Datensätze löschen, die nicht für Aggregate benötigt werden.
Bedingung: aggregate != 'A'
delete from samples
where aggregate != 'A'
and time > "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00";
Query OK, 11040 rows affected (0,568 sec)5. SQL-Statement
Nach Aggregate ermitteln, wie viele Datensätze der Außentemperatur für den Zeitraum vorhanden sind.
Ergebnis sind 230 Datensätze Außentemperatur.
Es wurden also nur 10 Datensätze innerhalb von 6 Stunden gelöscht.
Das ist sicher viel zu wenig.
select * from samples
where address = 4 and type = "VA"
and time > "2020-09-09 12:00:00"
and time < "2020-09-09 18:00:00"
order by time asc;
230 rows in set (0,002 sec)Der "Aggregate Intervall" funktioniert bei mir nicht.
Ich weiß natürlich nicht, wie Aggregate umgesetzt wurde.
Es gibt in MariaDB "Aggregate Functions".
Aber das ist mir im Moment zu hoch.
Man kann sich vorhandene "Functions" anzeigen lassen.
Da scheint aber keine "Aggregate Function" dabei zu sein.
MariaDB [mysql]> SHOW FUNCTION STATUS\G
Mal sehen, ob mir hier jemand weiterhelfen kann. 
Kannst ja mal Deine Werte anschauen und prüfen, ob ältere Werte tatsächlich nur noch im "Aggregate Intervall" vorliegen. Ich finde die Größe Deiner Datenbank ziemlich hoch.
Danke für den Tipp.
Und ja, Du hast Recht. Der "Aggregate Intervall" funktioniert bei mir nicht.
Wie kann ich das lösen bzw. das Zusammenfassen der alten Daten neu starten?
Hier mal zwei Beispiele der Außentemperatur aus Januar 2025 und Januar 2024.
MariaDB [p4]> select * from samples
-> where address = 4 and type = "VA"
-> and time > "2025-01-16 13:00:00"
-> and time < "2025-01-16 13:30:00"
-> order by time asc;
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
| address | type | aggregate | time | inssp | updsp | value | text | samples |
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
| 4 | VA | S | 2025-01-16 13:00:29 | 1737028829 | 1737028829 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:01:29 | 1737028889 | 1737028889 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:02:29 | 1737028949 | 1737028949 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:03:29 | 1737029009 | 1737029009 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:04:29 | 1737029069 | 1737029069 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:05:29 | 1737029129 | 1737029129 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:06:29 | 1737029189 | 1737029189 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:07:29 | 1737029249 | 1737029249 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:08:29 | 1737029309 | 1737029309 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:09:29 | 1737029369 | 1737029369 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:10:29 | 1737029429 | 1737029429 | 3.50 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:11:29 | 1737029489 | 1737029489 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:12:29 | 1737029549 | 1737029549 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:13:30 | 1737029610 | 1737029610 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:14:29 | 1737029669 | 1737029669 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:15:29 | 1737029729 | 1737029729 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:16:29 | 1737029789 | 1737029789 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:17:29 | 1737029849 | 1737029849 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:18:29 | 1737029909 | 1737029909 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:19:29 | 1737029969 | 1737029969 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:20:29 | 1737030029 | 1737030029 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:21:29 | 1737030089 | 1737030089 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:22:29 | 1737030149 | 1737030149 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:23:29 | 1737030209 | 1737030209 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:24:29 | 1737030269 | 1737030269 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:25:29 | 1737030329 | 1737030329 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:26:29 | 1737030389 | 1737030389 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:27:29 | 1737030449 | 1737030449 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:28:29 | 1737030509 | 1737030509 | 4.00 | NULL | 1 |
| 4 | VA | S | 2025-01-16 13:29:29 | 1737030569 | 1737030569 | 4.00 | NULL | 1 |
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
30 rows in set (0,001 sec)MariaDB [p4]> select * from samples
-> where address = 4 and type = "VA"
-> and time > "2024-01-16 13:00:00"
-> and time < "2024-01-16 13:30:00"
-> order by time asc;
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
| address | type | aggregate | time | inssp | updsp | value | text | samples |
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
| 4 | VA | S | 2024-01-16 13:00:58 | 1705406458 | 1705406458 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:01:58 | 1705406518 | 1705406518 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:02:58 | 1705406578 | 1705406578 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:03:58 | 1705406638 | 1705406638 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:04:58 | 1705406698 | 1705406698 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:05:58 | 1705406758 | 1705406758 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:06:58 | 1705406818 | 1705406818 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:07:58 | 1705406878 | 1705406878 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:08:58 | 1705406938 | 1705406938 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:09:58 | 1705406998 | 1705406998 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:10:58 | 1705407058 | 1705407058 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:11:58 | 1705407118 | 1705407118 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:12:59 | 1705407179 | 1705407179 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:13:58 | 1705407238 | 1705407238 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:14:58 | 1705407298 | 1705407298 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:15:58 | 1705407358 | 1705407358 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:16:58 | 1705407418 | 1705407418 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:17:58 | 1705407478 | 1705407478 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:18:58 | 1705407538 | 1705407538 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:19:58 | 1705407598 | 1705407598 | -0.50 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:20:58 | 1705407658 | 1705407658 | 0.00 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:21:58 | 1705407718 | 1705407718 | 0.00 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:22:58 | 1705407778 | 1705407778 | 0.00 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:23:58 | 1705407838 | 1705407838 | 0.00 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:24:58 | 1705407898 | 1705407898 | 0.00 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:25:58 | 1705407958 | 1705407958 | 0.00 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:26:58 | 1705408018 | 1705408018 | 0.00 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:27:58 | 1705408078 | 1705408078 | 0.00 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:28:58 | 1705408138 | 1705408138 | 0.00 | NULL | 1 |
| 4 | VA | S | 2024-01-16 13:29:58 | 1705408198 | 1705408198 | 0.00 | NULL | 1 |
+---------+------+-----------+---------------------+------------+------------+-------+------+---------+
30 rows in set (0,006 sec)
