0

Where/When is the use of RBAR buffering related to ASYNC_NETWORK_IO waits negotiated between the Client/SQL Server, or Is it always utilized as in that is just how SQL Server pushes data to the client?

Is Row By Agonizing Row (RBAR) a feature of ODBC or .NET Data Components, also, does anyone know if it can be turned off or overridden?

This stems from a SP that was tuned to run in 5 minutes, but when put in a report it falls in and out of ASYNC_NETWORK_IO for another 5 minutes.

Ross Bush
  • 14,648
  • 2
  • 32
  • 55
  • 1
    Isn't your second paragraph answered in the link you provided? – dfundako Jan 28 '19 at 21:28
  • @dfundako - Not really, it only hints that using a "shared memory connection" will share the buffer, however, that is only valid if the client and SQL Server share the same server. Also, it does not detail how the buffers are allocated and if it is an optional feature. – Ross Bush Jan 28 '19 at 21:45

1 Answers1

0

I think you're missing a reference. RBAR is a common acronym in the SQL Server community (I find it used quite commonly on the SQL Central forums) and it refers to a style of programming, not to a feature of any specific RDBMS or driver.

It refers to a (too common) style of programming, in which the data is retrieved one row at a time (probably using a cursor) and processed one by one, transforming, issuing additional selects, or stuff like that.

Usually who is using RBAR does it unknowingly, coming from a developer background, and not knowing "the SQL way" of doing things. Which is set-based, and usually approaches the problem at hand from perspective which is quite different from the one of a traditional (C, Java, C#) imperative language.

Source: https://www.red-gate.com/simple-talk/sql/t-sql-programming/rbar-row-by-agonizing-row/

Alberto Chiesa
  • 7,022
  • 2
  • 26
  • 53
  • Well that is weird because it is a SSRS dataset which calls a SP with no Cursors, just a lot of data. It am guessing it is built into SQL Server when pushing out large amounts of data to a client. – Ross Bush Jan 28 '19 at 21:38
  • Pay attention to the article you linked. RBAR is not the _only_ culprit. It is just a common one. If it's not the case, you should probably search elsewhere... – Alberto Chiesa Jan 28 '19 at 21:41
  • This stems from a SP that was tuned to run in 5 minutes, but when put in a report it falls in and out of ASYNC_NETWORK_IO for another 5 minutes. – Ross Bush Jan 28 '19 at 21:41
  • Well, it _could_ depend upon the usage the report is doing of the data returned by the SP. Not enough information to use, here. What I can say is that the problem is quite common. I saw this kind of waits (and I'm by any means a thorough expert in SQL Server) many times, when optimizing ETLS or (gosh!) Crystal Reports. – Alberto Chiesa Jan 28 '19 at 21:44