A downvoter has been targeting questions so that they get removed by Roomba. I don't know whether only my questions are targeted. Examples:
- History of the provisioned write capacity in DynamoDB beyond the last two weeks
- Column order in a DynamoDB table browsed through RazorSQL
- Maxing out the shared pool's memory by executing many UPDATE statements (ORA-04031)
Could this please stop? Thanks.
Here are the questions' details:
Is there any way to see the history of the provisioned write capacity for a DynamoDB table beyond the last two weeks? When I go to the Amazon AWS console, select a DynamoDB table and look at the monitoring tab, the time range does not allow me to go beyond two weeks. Is there any other place to look at that could give me a longer history?
I use RazorSQL to navigate in a DynamoDB database. What's the rationale behind the column order?
I am asking as the import tool uses the same order (which means if I import a CSV file it needs to be in the same ordering as the RazorSQL's column order):
I use RazorSQL 6.3.14 with Windows 7 SP1 x64 Ultimate.
I was executing a bunch of UPDATE statement. Around ~32.8K got executed and committed, then got the error:
cx_Oracle.DatabaseError: ORA-04031: unable to allocate 3896 bytes of shared memory ("shared pool","UPDATE COHORTS_A SET COHORT5...","sga heap(1,0)","kglsim object batch")
This made me think that the SQL area on Oracle DB grew too much to the point of maxing out the shared pool's memory.
Running the follow query would confirm it, but ironically and unsurprisingly I get the ORA-04031 error on it as well:
SELECT * FROM ( SELECT name, bytes/(1024*1024) MB FROM v$sgastat WHERE pool = 'shared pool' ORDER BY bytes DESC) WHERE rownum < 11;
What could have caused the shared pool to be full? If there's no room left in the SQL area cache, shouldn't older statements be removed?
I am running Oracle 11gR2 11.2.0.3.
Here are the SQL UPDATE statements I was executing and committing (I know I can optimize them):
UPDATE COHORTS_A SET COHORT2 = 6 WHERE HADM_ID = 22800 UPDATE COHORTS_A SET COHORT2 = 5 WHERE HADM_ID = 22801 UPDATE COHORTS_A SET COHORT2 = 5 WHERE HADM_ID = 22802 UPDATE COHORTS_A SET COHORT2 = 6 WHERE HADM_ID = 22803 UPDATE COHORTS_A SET COHORT2 = 6 WHERE HADM_ID = 22804 UPDATE COHORTS_A SET COHORT2 = 6 WHERE HADM_ID = 22805 UPDATE COHORTS_A SET COHORT2 = 6 WHERE HADM_ID = 22806 UPDATE COHORTS_A SET COHORT2 = 6 WHERE HADM_ID = 22807 UPDATE COHORTS_A SET COHORT2 = 6 WHERE HADM_ID = 22808 UPDATE COHORTS_A SET COHORT2 = 6 WHERE HADM_ID = 22809 UPDATE COHORTS_A SET COHORT2 = 6 WHERE HADM_ID = 22810 UPDATE COHORTS_A SET COHORT2 = 6 WHERE HADM_ID = 22811