OBS/Adminhilfe/MySQL Tipps: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Für diese Seite wurde eine Zugriffsbeschränkung eingerichtet. Falls du diese Nachricht siehst, bist du nicht berechtigt, diese Seite einzusehen.
Ecks (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
K (→MySQL Tipps) |
||
| Zeile 30: | Zeile 30: | ||
AND p_wgr.hwgr = DUP.hwgr | AND p_wgr.hwgr = DUP.hwgr | ||
AND p_wgr.liefnr = '700758' | AND p_wgr.liefnr = '700758' | ||
==Tabellen kopieren bei InnoDB== | |||
Habe mal ein wenig im Internet dazu geschaut und fast überall wird gesagt, man soll Tabellen bei InnoDB lieber per Dump kopieren. Bei MyISAM stellt das Kopieren kein Problem dar, aber bei InnoDB ist es sehr riskant und kann zu Problemen führen. | |||
Das Problem ist wohl, dass in der ibdata der Tablespace gespeichert wird und dieser nicht mit kopiert werden kann. | |||
http://serverfault.com/questions/367255/linux-mysql-is-it-safe-to-copy-mysql-db-files-with-cp-command-from-one-db-to | |||
Es gibt hier noch eine Anleitung wir man den Table Space manuell setzen kann, wofür aber einiges an manueller Arbeit pro Tabelle vorgenommen werden muss, was sich vermutlich am ehesten für Back Recovery eignet. | |||
http://www.chriscalender.com/tag/innodb-error-tablespace-id-in-file/ | |||
Nachdem ich noch etwas weiter lesen habe, habe ich herausgefunden , dass ab MySQL 5.6.6 wohl eine Möglichkeit besteht den Tablespace aus der Ibdata zu extrahieren: | |||
https://dev.mysql.com/doc/refman/5.6/en/tablespace-copying.html | |||
Hierfür muss jedoch pro Tabelle der Befehl | |||
FLUSH TABLES tabellenname FOR EXPORT; | |||
durchgeführt werden. Dadurch wird eine cfg Datei angelegt, die dann mit kopiert werden muss. | |||
Allerdings wird die Tabelle durch den Befehl gelockt und muss, nachdem sie kopiert wurde, per Befehl UNLOCK TABLES; wieder freigegeben werden, was eine Anwendung im laufenden Betrieb sehr unpraktikabel macht. | |||
</source><br/> | </source><br/> | ||
Version vom 16. März 2016, 14:10 Uhr
Dies ist eine zugriffsgeschützte Seite.
FAQ
- System Überwachung
- DEP deaktivieren
- Darstellung unter Windows 7
- Einwahl auf Windows 2000 Server
- Preislisten
- Datenbank Sicherung
- Customize
- Zentrale
- Support Macro
- Service Debug
- Historienprotokoll (Datenänderung OBS)
- Fernwartungsprobleme
- Startparameter
- Fehler beim Kassenabschluss
- Diverse Informationen
Häufige Fehler FAQs
Allgemeines
Wiki Hilfe
Syntax
Wiki-Gruppen Benutzerlisten
MySQL
Programmierung und Mergen
Delphi
Einrichtung
Git/SmartGit
Programm Update
PAX
Nützliche Funktionen
SteVe
OBS-Administration / Installation
Einrichtung
MySQL
Dienste
Kasse/Notfallkasse
Replikation
Zentrale
Fleet-Management einrichten
OBS Umzug
Admin Funktionen
Service Firmen
F10
- A ras.pbk
- B Command Line Interpreter
- C File Zilla Benutzer XML erzeugen
- D1 OBS_UPDATE.EXE zum OBS Update Server hochladen
- D2 SUPPORT_MACRO zum OBS Update Server hochladen
- H1 Remote Service Protokoll-Übersicht (Alles)
- H Remote ServiceProtokoll-Übersicht
- I Remote Service Commands
- I1 (Admin) Globaler Hinweis für Updates
- J Liste der OBS Updates
- K Angemeldete Service Firmen
- L Systeminformationen einlesen
- M Kundendaten anzeigen
- M1 Kundendatenbankinformationen anzeigen
- N Kundendaten einlesen
- O Kunden-Update Informationen anzeigen
- P Modul Registrierung OBS
- Q App Verwaltung
- S1 Firmen Statistik Protokolle OBS
- S2 Statistik Notfallkassen
O Support
D Programmierer-Tools
V Crypt Autologin Edit
J Update Marko Lib/Pmode/Script Lib
kundenspezifische Anpassungen
OBS Protokolle
OBS DEMO
Shop-Administration
modified eCommerce
modified eCommerce 2.x
modified eCommerce 1.06
Amazon
VShop 4.0
Kundeninformationen
MySQL Tipps
MySQL DELETE Statements
Wenn man ein DELETE Statement braucht, in dem man einen JOIN auf auf die Tabelle benötigt, aus welcher man die Daten löschen möchte, gibt MySQL einen Fehler aus, dass man nicht auf die Tabelle joinen darf, aus welcher man löschen möchte.
Als Beispiel, doppelte Warengruppen aus der Wortmann Artikelpflege löschen:
DELETE
FROM P_WGR
WHERE EXISTS (
SELECT sys_uid
FROM P_WGR AS DUP
WHERE P_WGR.hwgr = DUP.hwgr
AND P_WGR.wgrname = DUP.wgrname
AND P_WGR.sys_uid <> DUP.sys_uid
AND liefnr = '700758')
ORDER BY hwgr;
So lässt sich dieses aber umgehen:
DELETE
FROM p_wgr
USING p_wgr, p_wgr AS DUP
WHERE p_wgr.sys_uid > DUP.sys_uid
AND p_wgr.hwgr = DUP.hwgr
AND p_wgr.liefnr = '700758'
==Tabellen kopieren bei InnoDB==
Habe mal ein wenig im Internet dazu geschaut und fast überall wird gesagt, man soll Tabellen bei InnoDB lieber per Dump kopieren. Bei MyISAM stellt das Kopieren kein Problem dar, aber bei InnoDB ist es sehr riskant und kann zu Problemen führen.
Das Problem ist wohl, dass in der ibdata der Tablespace gespeichert wird und dieser nicht mit kopiert werden kann.
http://serverfault.com/questions/367255/linux-mysql-is-it-safe-to-copy-mysql-db-files-with-cp-command-from-one-db-to
Es gibt hier noch eine Anleitung wir man den Table Space manuell setzen kann, wofür aber einiges an manueller Arbeit pro Tabelle vorgenommen werden muss, was sich vermutlich am ehesten für Back Recovery eignet.
http://www.chriscalender.com/tag/innodb-error-tablespace-id-in-file/
Nachdem ich noch etwas weiter lesen habe, habe ich herausgefunden , dass ab MySQL 5.6.6 wohl eine Möglichkeit besteht den Tablespace aus der Ibdata zu extrahieren:
https://dev.mysql.com/doc/refman/5.6/en/tablespace-copying.html
Hierfür muss jedoch pro Tabelle der Befehl
FLUSH TABLES tabellenname FOR EXPORT;
durchgeführt werden. Dadurch wird eine cfg Datei angelegt, die dann mit kopiert werden muss.
Allerdings wird die Tabelle durch den Befehl gelockt und muss, nachdem sie kopiert wurde, per Befehl UNLOCK TABLES; wieder freigegeben werden, was eine Anwendung im laufenden Betrieb sehr unpraktikabel macht.