One of the practices mentioned in the SQL Toolkit user's guide is a "must have" - that is making a separate table containing your key, and then referencing the key by its index and not the value. If you put the key value itself into the SQL statement, then anyonw can look at query history, see the key value, and easily apply it to your data. By using the index of a table holding the key, you can lock down the table from curious eyes. They may know where the table is and what its name is, but cannot actually see its contents. Either way, if your SQL puts the key in the query itself, it may as well not encrypt at all.
I would suggest not putting the encryption in the load, but load up a staging table, copy the data into the target table from the staging table with the encryption in the transfer. This will put the encryption in the parallel stream (e.g a CTAS) rather than the loading stream and take the pressure off the host. Even as I write this, I am not sure you can actually use this part of the SQL toolkit in the nzload and I don't have immediate access to a machine to check it out. Either way, it's always better to do computations in the parallel stream, not on nzload, because nzload comes through the host and is not as strong in the transformation as the parallel streams are.
