network profile
| bio | website | |
|---|---|---|
| location | Knoxville, TN | |
| age | 25 | |
| visits | member for | 2 years, 1 month |
| seen | 10 hours ago | |
| stats | profile views | 2 |
|
12h |
asked | BLOB storage in rows |
|
Jan 10 |
comment |
FREETEMPORARY on blob with no reference That seems to be about it then. We'll have to look at it a bit more, but we need to find a way to kill these sessions from the application side; maybe giving them some sort of TTL? Appreciate all the help, guys. Thanks. |
|
Jan 9 |
comment |
FREETEMPORARY on blob with no reference Honestly, I'm not sure. The DBCP is the connection pool we use with Tomcat and Spring's JdbcTemplate is what we're using to run the queries. Considering that JdbcTemplate swaps out bind variables for us, we're assuming that it is creating an anonymous block behind the scenes. |
|
Jan 9 |
comment |
FREETEMPORARY on blob with no reference @JackDouglas running select * from v$temporary_lobs; reveals that for the current session I still have 4 in the ABSTRACT_LOBS column. This is after running the query by itself (no anonymous block) four times in SQL Developer. |
|
Jan 9 |
comment |
FREETEMPORARY on blob with no reference @DavidMann So you're saying that killing the session will cause the temp space to clear up? And if so, is each connection from a Tomcat DBCP considered a separate session? |
|
Jan 9 |
asked | FREETEMPORARY on blob with no reference |
|
Aug 30 |
comment |
Get timing on individual queries in Anonymous code block this seems like it will do the job. thanks! |
|
Aug 30 |
accepted | Get timing on individual queries in Anonymous code block |
|
Aug 30 |
revised |
Get timing on individual queries in Anonymous code block edited title |
|
Aug 30 |
asked | Get timing on individual queries in Anonymous code block |
|
Aug 26 |
accepted | FBI on function with concatenated string |
|
Aug 26 |
accepted | Full Name search query |
|
Aug 26 |
asked | Full Name search query |
|
Aug 26 |
comment |
FBI on function with concatenated string No NLS issues, query is a LIKE (see updated question), and columns are nullable. The table is 80531 rows in the test environment, but I need to make sure this query will use the index in production to save on query cost. Row count in production could be in excess of 1M rows. |
|
Aug 26 |
awarded | Editor |
|
Aug 26 |
revised |
FBI on function with concatenated string added 356 characters in body |
|
Aug 25 |
asked | FBI on function with concatenated string |
|
Apr 25 |
awarded | Scholar |
|
Apr 25 |
accepted | MAX for each subset |
|
Apr 25 |
awarded | Supporter |
