DEA-C01 Practice Question 48: Redshift Load Error Diagnosis

STL_LOAD_ERRORS "displays the records of all Amazon Redshift load errors" and carries precisely the columns the engineer needs: filename ("complete path to the input file for the load"), line_number, colname ("field with the error"), raw_line ("raw load data that contains the error"), raw_field_value and err_reason. The documentation then says to "query STL_LOADERROR_DETAIL for additional details, such as the exact data row and column where a parse error occurred, after you query STL_LOAD_ERRORS to find out general information about the error", joining the two on the query ID. pg_last_copy_id() conveniently returns the query ID of the most recent COPY.

Option A looks at the wrong table. STL_LOAD_COMMITS records files that loaded successfully. It can tell you which files got through, but it holds no error reason, no line number, and no bad value.

Option B is the best distractor because NOLOAD genuinely does validate the input without loading it. But it does not print offending values to the client; the errors it finds are written to STL_LOAD_ERRORS, so the engineer ends up querying that table anyway. It also re-reads all 60 files for a failure whose details have already been recorded.

Option C records API activity: who called GetObject, from where, and when. It says nothing about the contents of a row or why Redshift could not parse it, and it would have to be enabled before the failure to be of any use at all.

Reference: STL_LOAD_ERRORS