A partner's nightly extract arrives by file transfer, but the import loads only part of it and several rows contain garbled characters. The received file's size also differs from the size stated in the partner's manifest, which includes a SHA-256 hash of the file. What should the DBA do first?

Data corruption during acquisition usually happens in transit or in storage: an interrupted transfer, a transfer mode that alters bytes, such as an ASCII-mode FTP transfer of a binary or compressed file, or a faulty disk. A cryptographic hash such as SHA-256 provides an integrity check because any change to the file's bytes produces a different value. Computing the hash of the received file and comparing it with the partner's manifest confirms whether the file is intact; a mismatch, supported here by the size difference, means the file must be transferred again, using binary mode or an integrity-checked protocol, before any load is attempted. Widening the target columns treats a symptom; the bytes are already wrong, so a larger column would simply store garbage. Skipping bad rows and reporting success hides the problem and produces an incomplete, inaccurate dataset that downstream users will trust. Index fragmentation affects query performance, not the content of incoming rows, and rebuilding indexes cannot repair a corrupted file. Exam caveat: validate integrity before loading and fail the job loudly when validation fails, because silent partial loads are worse than an obvious failure. Operational check: after the re-transfer, verify the hash and file size match the manifest, load into staging, and compare row counts and control totals with the partner's figures.