Before the load you executed the report RSDU_PSA_PARTNO_CHECK in "repair" mode for the related PSA table.
The report RSDU_PSA_PARTNO_CHECK initializes the value of the field PARTNO of an PSA (persistent staging area table) in a way that for performance reasons the whole column gets dropped and added again at the end of the table, in other words it changes the sequence of fields in the table, hence the data base object gets changed, while the dictionary definition as well as its runtime object stays untouched.
This change is not reflected in the SQL statement cache of a work process. When the prepared statement gets called, it tries to insert the data in wrong sequence.
Due to data type conflicts the operation cancels with the afore-mentioned dump.
最根本的方案：升级hana，This problem will be fixed with HANA Revision 112.05 and 122.
次优方案：As work around you can either restart application server workprocess by setting the parameter "rdisp/wp_auto_restart" to a small value immediately after you have executed the report RSDU_PSA_PARTNO_CHECK in repair mode. After you can be sure that each process got restarted, reset the parameter back to its old value. This ensures that the SQL cache entries get recreated with the correct sequence. Please refer to SAP note 101717 regarding the parameter rdisp/wp_auto_restart.
A restart of the application server does have the same effect, but is not required.