The DBA is correct - if the database is part of an Availability Group (AG), it has to be in the FULL recovery model. This is because of the way AGs work - they ship transaction log blocks from the primary server to the secondary server(s). So all the detailed log records provided by the FULL recovery model are needed.
You could remove the database from the AG during your initial data load.
ALTER AVAILABILITY GROUP [YourAG]
REMOVE DATABASE [YourDatabaseName];
However, the (potentially major) downside to this is that the secondary will need to be "re-initialized" once the data load is done. That means either using "automatic seeding" to replicate the entire primary database to the secondary server(s) (Enable automatic seeding on an existing availability group), or taking a backup of the primary, restoring it on each of the secondaries, and then re-adding the database to the AG (Prepare a secondary database for an Always On availability group).
Depending on how big the database is after the data load, this might be "no big deal," or it could be a real hassle. But yeah, that's the other option available to the DBA basically.
By the way, regarding this:
we are seeing within the activity monitor a pile up of queries in a wait state
You didn't mention the actual wait, but unless it's HADR_SYNC_COMMIT or WRITELOG, removing from the AG / switching to SIMPLE recovery might not help.
Even if these are your waits, be aware that you are treating a symptom. If the app ever needs to dump in data like this once it's live, you probably won't be able to monkey with the AG or recovery models.
Maybe your app could reduce the amount of log data generated by grouping some of its transactions into larger batches.
Or maybe you need to investigate the network speed between the primary and secondary servers (keeping in mind how to properly measure AG throughput).
Those are just some possible remedies. All of this is just to say that you're better off, in the long run, figuring out the root cause of this "wait state leading to application errors" business now rather than later.
The waits you've showed are lock waits, indicative of a classic blocking chain.
Notice the "Blocked By" column is 131 for all of the rows in the screenshot. That's a "Session ID" (first column of Activity Monitor). Keep following that chain until you find the lead blocker ("Blocked By" will be blank), and look in the "Wait Type" column to see what it is waiting on. That's where you should focus your efforts to unravel the root cause.
Regarding this update:
Apparently the default for doing a backup of the logging directory was set to a large value. When that kicked off to clear out the logging (incremental log thing??), it makes the whole system stutter and caused the issue. That's my current theory. Now he has changed it to 5 minutes and so far, all we see is a stutter and recovery on our side. I have my engineer gather more real data (the actual block if he can catch it).
It sounds like increased resource usage when transaction log backups occur is interfering with your workload. One solution to this would be to run transaction logs more frequently, as the DBA did. You could even run the backups every minute if they finish fast enough.
All that said, the original solution of switching to SIMPLE recovery is a viable option if it's feasible to re-initialize the secondary after the initial load is done.
