Mimic-code: Datei chartevents.csv konnte nicht stat. unbekannter Fehler

Haben Sie die Integrität Ihrer Kopie von chartevents.csv anhand der Prüfsummendateien auf der Downloadseite des Projekts überprüft? Möglicherweise wurde es während des Downloads oder der Dekomprimierung beschädigt.

Ja, ich habe den Befehl md5 checksum_md5_zipped.txt verwendet und mit allen Tabellen ist alles in Ordnung ...

Ich habe es auch mit gezippten Daten versucht und postgres_load_data script_7zip ausgeführt. In diesem Fall erhalte ich: Zeilenumbruch ohne Anführungszeichen in Daten gefunden. Hinweise: Verwenden Sie ein CSV-Feld in Anführungszeichen, um eine neue Zeile darzustellen.

Ich habe auch md5 checksum_md5_unzipped.txt überprüft und alles ist in Ordnung.

Es hört sich so an, als ob das Skript, das Sie ausführen, und die Daten, die Sie haben, nicht übereinstimmen. Ich würde sicherstellen:

1. Alle Dateien befinden sich im selben Verzeichnis
2. Alle Dateien haben dieselbe Dateierweiterung; zB sind sie alle .csv.gz
3. Sie führen die Datei postgres_load_data_7zip.sql entweder (i) aus demselben Ordner aus oder (ii) nachdem Sie mimic_data_dir so konfiguriert haben, dass es auf das Datenverzeichnis verweist.

Darüber hinaus ist es wirklich schwierig, remote zu debuggen, ohne weitere Informationen wie einen Screenshot Ihres Ordner-Setups, Ihre Systeminformationen, die genauen Befehle, die Sie ausgeführt haben, und die genaue Fehlermeldung.

Hallo,

Vielen Dank für Ihre Antwort.

1. Alle Dateien befinden sich im selben Verzeichnis
2. Alle Dateien haben die gleiche Dateierweiterung csv
3. Ich führe die Datei posgres_load_data.sql aus, nachdem ich mimic_data_dir so konfiguriert habe, dass es auf das Datenverzeichnis verweist.
   Hier sind meine genauen Befehle und Fehler, die ich erhalten habe.
   
   
   

Super das ist sehr hilfreich, danke für die zusätzlichen Infos. Ich denke, es ist so einfach, dass die Datei nicht im Ordner ist. Können Sie überprüfen, ob Ihr Ordner C:/Users/Lejla/Desktop/MIMICIII die Datei CHARTEVENTS.csv enthält?

Es kann sein, dass Sie versucht haben, alle komprimierten Dateien zu extrahieren, dies jedoch bei Chartevents fehlgeschlagen ist und Sie nur eine .csv.gz Datei haben (Gründe können sein, dass die extrahierte Datei 33 GB groß ist und Sie keinen Speicherplatz mehr haben oder Ihr Dateisystem ist FAT32 (!), oder wer weiß). In diesem Fall möchten Sie vielleicht das Ladeskript bearbeiten, um es direkt von .csv.gz zu laden. Sie können dies tun, indem Sie Folgendes ersetzen:

\copy CHARTEVENTS from 'CHARTEVENTS.csv' delimiter ',' csv header NULL ''

mit

\copy CHARTEVENTS from PROGRAM '7z e -so CHARTEVENTS.csv.gz' delimiter ',' csv header NULL ''

Vielen Dank für die Antwort. Ich habe dieses Mal versucht, mit der ZIP-Datei zu arbeiten und das Skript dafür auszuführen. Dieses Mal habe ich andere

Nachricht... Vielleicht hilft es.

Macht es Ihnen etwas aus, den Inhalt des Verzeichnisses anzuzeigen?

Ich habe nichts dagegen.hier ist der Inhalt meines Ordners

Okay, could not stat file "CHARTEVENTS.csv": Unknown error ist eigentlich ein Fehler in PostgreSQL 11. Unter der Haube ruft es fstat() auf, um sicherzustellen, dass die Datei kein Verzeichnis ist, und leider ist es fstat() ein 32-Bit-Programm, das keine großen Dateien wie Chartevents verarbeiten kann. Ich habe den Build unter Windows mit PostgreSQL 10.5 getestet und diesen Fehler nicht erhalten, daher denke ich, dass er ziemlich neu ist.

Die beste Problemumgehung besteht darin, die Dateien komprimiert zu halten (dh sie als .csv.gz Dateien zu speichern) und 7zip zu verwenden, um die Daten direkt aus komprimierten Dateien zu laden. Im Test schien dies noch zu funktionieren. Eine ziemlich detaillierte Anleitung dazu gibt es hier: https://mimic.physionet.org/tutorials/install-mimic-locally-windows/

Die kurze Version von oben ist, dass Sie die .csv.gz Dateien behalten, die 7zip-Binärdatei zu Ihrem Windows-Umgebungspfad hinzufügen und dann die postgres_load_data_7zip.sql Datei aufrufen, um die Daten zu laden. Sie können die Datei postgres_checks.sql nach allem verwenden, um sicherzustellen, dass Sie alle Daten richtig geladen haben.

Bearbeiten: Bei Ihrem späteren Fehler, bei dem Sie diesen 7zip-Ansatz verwenden, bin ich mir nicht sicher, warum er nicht geladen wird. Versuchen Sie, nur die Datei ADMISSIONS.csv.gz erneut herunterzuladen und zu sehen, ob Sie immer noch denselben Fehler erhalten. Vielleicht gibt es eine neue Version von 7zip, bei der ich das Skript aktualisieren muss oder so!

Hallo,
Vielen Dank für die ausführliche Erklärung. Ich habe PostgreSQL 10.5 installiert und jetzt läuft der Prozess. Ich denke, es wird viel Zeit in Anspruch nehmen, alle Tabellen zu laden, aber ich erhalte "Unbekannter Fehler" nicht mehr. Vielen Dank für alle Hilfestellungen.

Toll!

Okay, could not stat file "CHARTEVENTS.csv": Unknown error ist eigentlich ein Fehler in PostgreSQL 11. Unter der Haube ruft es fstat() auf, um sicherzustellen, dass die Datei kein Verzeichnis ist, und leider ist es fstat() ein 32-Bit-Programm, das keine großen Dateien wie Chartevents verarbeiten kann. Ich habe den Build unter Windows mit PostgreSQL 10.5 getestet und diesen Fehler nicht erhalten, daher denke ich, dass er ziemlich neu ist.

Die beste Problemumgehung besteht darin, die Dateien komprimiert zu halten (dh sie als .csv.gz Dateien zu speichern) und 7zip zu verwenden, um die Daten direkt aus komprimierten Dateien zu laden. Im Test schien dies noch zu funktionieren. Eine ziemlich detaillierte Anleitung dazu gibt es hier: https://mimic.physionet.org/tutorials/install-mimic-locally-windows/

Die kurze Version von oben ist, dass Sie die .csv.gz Dateien behalten, die 7zip-Binärdatei zu Ihrem Windows-Umgebungspfad hinzufügen und dann die postgres_load_data_7zip.sql Datei aufrufen, um die Daten zu laden. Sie können die Datei postgres_checks.sql nach allem verwenden, um sicherzustellen, dass Sie alle Daten richtig geladen haben.

Bearbeiten: Bei Ihrem späteren Fehler, bei dem Sie diesen 7zip-Ansatz verwenden, bin ich mir nicht sicher, warum er nicht geladen wird. Versuchen Sie, nur die Datei ADMISSIONS.csv.gz erneut herunterzuladen und zu sehen, ob Sie immer noch denselben Fehler erhalten. Vielleicht gibt es eine neue Version von 7zip, bei der ich das Skript aktualisieren muss oder so!

Die Verwendung von PostgreSQL 10.11 hat mir geholfen ... danke

Super das ist sehr hilfreich, danke für die zusätzlichen Infos. Ich denke, es ist so einfach, dass die Datei nicht im Ordner ist. Können Sie überprüfen, ob Ihr Ordner C:/Users/Lejla/Desktop/MIMICIII die Datei CHARTEVENTS.csv enthält?

Es kann sein, dass Sie versucht haben, alle komprimierten Dateien zu extrahieren, dies jedoch bei Chartevents fehlgeschlagen ist und Sie nur eine .csv.gz Datei haben (Gründe können sein, dass die extrahierte Datei 33 GB groß ist und Sie keinen Speicherplatz mehr haben oder Ihr Dateisystem ist FAT32 (!), oder wer weiß). In diesem Fall möchten Sie vielleicht das Ladeskript bearbeiten, um es direkt von .csv.gz zu laden. Sie können dies tun, indem Sie Folgendes ersetzen:

\copy CHARTEVENTS from 'CHARTEVENTS.csv' delimiter ',' csv header NULL ''

mit

\copy CHARTEVENTS from PROGRAM '7z e -so CHARTEVENTS.csv.gz' delimiter ',' csv header NULL ''

Danke, das hat bei mir funktioniert:
\copy my_table_name from program 'cmd /c type input_data.csv' delimiter ',' csv header;
input_data.csv wie 11GB Größe.

Das Problem mit "Kann keine großen Dateien kopieren" tritt für die Versionen 11 und 12 auf. Aber für 10 ist ok. Wie kann man es überschreiben, ohne eine Datendatei zu komprimieren, aber vielleicht einige Postgresql-Programmdateien von v.10 auf v 11 und 12 hochzurüsten/zu tauschen?
Problemumgehung:
kopiere t(c,d) aus dem Programm 'cmd /c "type x:\pathto\file.txt"' mit (Text formatieren);
-ist für meine Bedürfnisse ziemlich langsam. Ich brauche die Geschwindigkeit des Standardkopierbefehls

Sie könnten erwägen, andere Befehlszeilentools zu verwenden, um die Datei in mehrere Dateien aufzuteilen und dann die einzelnen Dateien einzeln zu laden. Auf Unix-Systemen kann dies mit split und Sie können die GNU-Coreutils für Windows installieren, um sie zu verwenden.

Ich glaube, ich habe das gleiche Problem wie Sie, aber ich verwende die sehr neue Version 12. Gibt es eine Möglichkeit, das Problem zu lösen? Komprimierte Dateien verwenden?

Ja, wenn ich mich richtig erinnere, sind die komprimierten Dateien < 4 GB und Sie vermeiden diesen Fehler, indem Sie die komprimierten Ladeskripte (7z oder gzip) verwenden.

OK, ich werde diese Methode jetzt ausprobieren, vielen Dank für deine Antwort

Also keine Problemumgehung OHNE Komprimierung oder Aufteilung zu verwenden? Verwendung der Version 10 des COPY-Befehls von Postgresql für 11, 12-Engine?
Wie gesagt:
Ich brauche die Geschwindigkeit des Standardkopierbefehls, aber für große Dateien + 12er-Version
und das ist für meine Bedürfnisse von entscheidender Bedeutung.

Nun, PostgreSQL ist Open Source, Sie können also gerne versuchen, selbst einen Fix beizutragen :)

Hier ist die entsprechende Diskussion: https://www.postgresql.org/message-id/20181104000405.GA1743%40paquier.xyz

Ansonsten haben Sie die drei in diesem Thread vorgeschlagenen Workarounds (Version ändern, komprimierte Dateien verwenden, Datei in mehrere Teile aufteilen). Ich bin sicher, es gibt auch andere Workarounds.

Ist es nicht naheliegend, einen funktionierenden Teil des Codes von Version 10 der COPY-Funktionalität in 11 und 12 zu migrieren? Oder ist es so hartcodiert, dass es für alle zum Absturz führt? :)

@ghYura Dies ist eine von der Community verwaltete Ressource. Wenn Sie also Vorschläge zur Verbesserung der Codebasis haben, würde ich vorschlagen, eine Pull-Anfrage zu stellen.

Ich habe den Fehler beim Laden der CSVs in die Tabellen sowohl in der 12.X- als auch in der 13.X-Version erhalten, aber es funktioniert wie ein Zauber in der PostgreSQL-Version 10.15. Danke an alle für die Hilfe :)