Using data tab causes SD users to be black-listed! Why is this happening?

Question

Several SQL Developer users in our workgroup were recently black-listed by our IT department for submitting queries that ran for hours against large tables. Many of these users emphatically stated that they had not submitted ANY queries. Finally someone theorized that clicking on the data tab to view a few rows of data may be causing SD to to submit a SELECT * query to Oracle. Yikes! There are now hundreds of users out there using SD with more coming on board every week across the enterprise. Can such an innocuous action of clicking on a tab actually be causing this problem and if so how can we globally prevent SD from doing this?

Answer 1

>
If what folks on this forum are saying is true, that unbeknownst to the user, clicking on the data tab is, in the background, submitting a SELECT * FROM for the entire table, then the SD software should be smart enough and courteous enough to give the user a warning and choice to continue or limit the number of rows delevered! No ifs, ands, or buts about it.
>
The number of rows actually fetched each time from the server uses the 'Sql Array Fetch Size' preference setting. This setting is '50' by default. You access it by 'Tools -> Preferences -> Database -> Advanced.
The user can choose to scroll through as many rows as desired. If the user performs no scrolling beyond the 50 rows then no more rows will be fetched.
>
That is precisely what SQL Developer should do out of the box!
>
And that IS what SQL Develper does 'out of the box'.
>
Several SQL Developer users in our workgroup were recently black-listed by our IT department for submitting queries that ran for hours against large tables. Many of these users emphatically stated that they had not submitted ANY queries. Finally someone theorized that clicking on the data tab to view a few rows of data may be causing SD to to submit a SELECT * query to Oracle
>
A 'SELECT * FROM myTable' query will NOT run for hours. That query will almost always perform a full table scan of the table since rarely will any index contain ALL of the columns of the table including NULL columns (null columns are not indexed by heap indexes; only by bitmap indexes).
A full table scan (without an ORDER BY to sort the data) simply reads every block of the table. That reading will not prevent any other user/session from doing whatever DML they need to run.
A user can elect to SORT the data and in that case Oracle will have to sort the ENTIRE table BEFORE it can return any data to the user. A sort can definitely use a lot of resources in the background and can definitely interfere with other users/sessions that need those resources.
But the SORT issue will apply to ANY tool being used including 'SQL Assistant'. No tool exists that can feed 20 sorted rows to the user BEFORE the data has been sorted. And no tool exists that can exert ANY control over the Oracle sort process. The tool will NOT get any data until the sort is 100% complete.
Always make sure you are comparing the same use cases when you make comparisons like that.
1. Basic use of sql developer by selecting a data tab WILL issue a SELECT * FROM . . . query to the backed
2. If the filter options have NOT been modified to include sorting the query will execute very quickly and fetch the first 50 rows. Additional rows will ONLY be fetched if the user asks for them.
3. A pure SELECT * FROM query will NOT run for hours on the backend.
4. ANY tool that issues a SELECT * FROM . . . ORDER BY query will cause Oracle to perform a full table scan.
5. The likely cause of what appears to be a simple SELECT * FROM query is usually a user that selects the data tab and then goes home for the weekend leaving their machine on. That query will remain the the library cache and the session will remain but there will be no real activity or resources being used.
If you have ANY evidence that contradicts any of the above please post the specifics.
As previously mentioned by another responder the user CAN perform