Re: Log in Storm Caused Database Crash

Am I understanding this correctly and you were doing a deliberate load test?

You can't really define a "breaking point" solely on limiting the number of sessions. It depends on many many more factors, particularly on what those sessions are actually doing, how well your application was designed for concurrency, your underlying data model, etc, etc. Of course it also depends on your architecture (single instance vs RAC) and how well the application was written for either of those.

But if you are running load tests, I'd say you are on the right path already. I'd however start with a lower threshold and monitor the system for a while to watch for concurrency issues, how well the I/O subsystem handles it, CPU load, etc etc... Then gradually increase the amount of workers until you start seeing problems. You can cripple almost any system by hitting it with 100 new connections per second for long periods of time. I'd start slower and ensure that it handles that well first.

With an approach like this - assuming that your load test is producing a somewhat realistic load profile (and not just connect/disconnect) - this will allow you to effectively determine your capacity.

Stefan

On Mon, Oct 2, 2017 at 11:45 AM, Ravi Teja Bellamkonda < raviteja.bellamkonda7_at_gmail.com> wrote:

> Hi Upendra,
>
> Thank you for your response. This is an internet facing application and we
> were expecting a burst load to check for the capacity of the system. Is
> there a way to measure what no of sessions in the database is breaking
> point. I was doubting if any Sub-Optimal Connection Pooling might have
> caused this.
>
> Highly appreciated your help here.
>
> On Sun, Oct 1, 2017 at 7:39 PM, Upendra nerilla <nupendra_at_hotmail.com>
> wrote:
>
>> Is this an internet facing application or internal? If it is external
>> facing application, investigate if there was DoS type attack or a spike in
>> the user sessions due to any issues with application servers?
>>
>>
>> If you need to isolate where the connections originated from, you could
>> look into DBA_Hist views.
>>
>>
>> You may want to start with this one.. https://docs.oracle.com/cd/B19
>> 306_01/server.102/b14237/statviews_3125.htm#REFRN23400
>>
>>
>> DBA_HIST_ACTIVE_SESS_HISTORY - Oracle Help Center
>> <https://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_3125.htm#REFRN23400>
>> docs.oracle.com
>> DBA_HIST_ACTIVE_SESS_HISTORY. DBA_HIST_ACTIVE_SESS_HISTORY displays the
>> history of the contents of the in-memory active session history of recent
>> system activity.
>>
>> Also look into any application server logs and see if there were any
>> issues with the application server itself..
>>
>>
>> -Upendra
>>
>>
>> ------------------------------
>> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on
>> behalf of Ravi Teja Bellamkonda <raviteja.bellamkonda7_at_gmail.com>
>> *Sent:* Sunday, October 1, 2017 9:25 PM
>> *To:* oracle-l
>> *Subject:* RE: Log in Storm Caused Database Crash
>>
>> Hi List,
>>
>> We ran into an issue recently and wanted some help in figuring out this
>> issue.
>>
>> Database was not responding and one thing from AWR observed before fail
>> over was the login storm.
>>
>> [image: Inline image 1]
>>
>>
>> Logons cumulative also increased during this interval.
>>
>> [image: Inline image 2]
>>
>> Logons cumulative were 1237 in total in the before AWR report. Any
>> suggestions are highly appreciated.
>> --
>> Thanks & Regards,
>> Ravi Teja
>>
>>
>
>
> --
> Thanks & Regards,
> Ravi Teja Bellamkonda
>

-- 
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat |
_at_zztat_oracle










--
http://www.freelists.org/webpage/oracle-l





image/png attachment: image.png



image/png attachment: image.png