OracleBulkCopy default implementation

The Oracle provider has, in my opinion, strange defaults when it comes to bulk copy.

1. It defaults to multiple rows.

Wouldn’t it be better to check if OracleBulkCopy is available? Unfortunately it’s available only in the native provider (not classic-managed, nor core-managed) and Oracle seems in no hurry to fix that. But when using native, isn’t that the best option?

2. Multiple rows defaults to INSERT ALL

With Oracle, isn’t INSERT INTO actually a better choice? It uses array parameters to send a simple, short, parameterized insert statement with N sets of parameters at once.

You can easily and efficiently send 100 rows at a time with a short SQL statement, it’s more efficient than generating a huge 100 x P parameters INSERT ALL statement.

---

It’s not critical as you can easily change the defaults, but I wonder why the best options aren’t the actual defaults?

Given that it changes the generated queries when users upgrade, that would qualify as a major release change, of course… unless we can piggy-back another new flag to change the defaults, e.g. the Oracle 12 dialect proposed in #1879

[jods4]

@viceroypenguin I changed my mind on what is the “better” default but it’s still not the one proposed by linq2db.

I changed my mind about native bulk because even though it’s best in terms of throughput, non-transactional is very dangerous if you’re not aware.

Using array bindings is the IMHO the right default, as it’s simply more efficient than a “SELECT ALL”. It uses way less parameters, with a short and simple SQL statement. You can easily batch hundreds of rows in one round-trip. “SELECT ALL” needs one parameter per value per row, generates a query that’s as long as the number of rows you want to insert, it’s not efficient to send and parse and could run into max query length and max # parameters if you try to scale it up to more rows per roundtrip.

[jods4]

Everything works fine for me, yes (in the limits of how Oracle works, anyway).

I opened this issue just to suggest more performant default values. INSERT ALL can generate very long SQL queries and the last one sent is probably different each time if the number of elements modulo batch size isn’t constant (which implies new execution plan and cache pollution).

Array binding queries are short and natively handled.