A session means a connection between client and server. In order for that session to execute client query a process server must be created which need to occupy some memory. So number of session depends on physical memory of server. The size of database depends on server storage and has to do nothing with number of sessions.
Your original question from the other thread I linked above, was :
"Lets say the size of my PROD database is 300 GB then what should be the size of SGA, temp Tbs and undo Tbs.
I know it depends on many other factors but is their any general rule ?"
I think Billy was trying to explain size of db (again, define what is size) and SGA have nothing to do with eachother. That's it.
As Billy said... <mod. action: please, when quoting, insert reference link Database projects and DBA?>
Could you please explain how small database support large
no. of sessions and transactions up to 1000 and 100 respectively..
Whereas large database support only 10 sessions and 1 query per minute..
Message was edited by: NicolasGasparotto
there is no direct relationship between the total size of the datafiles, the number of concurrent sessions, the number of concurrent SQL statements, or transaction rate.
Each in an independent metric.
A database can be large/small (here another term also known as VLDB i.e. Very Large Database) in term of :
1.number of datafiles
2.size of datafiles
3.actual data in the database
4.number of concurrent SQL or PL/SQL
6.security and/or other complex configuration
8.number of DBAs
9.number of dependent applications i.e. Throughput
10.availability i.e. 24x7 up database
I guess, Billy is saying that there are chances that a database which may be large in any above points, but it is being access by suppose 10-15 users, and like opposite that some database is small in size and number of concurrent users are more or huge, he is just giving you an example.
>I am a fresher (OCP certified) and I have no process/project knowledge.
Don't worry about being fresher. Since you have no project knowledge, it means you are having plenty of time to learn the things, to invest your time to have a successful and planned career. Never feel yourself as a hopeless/helpless, because this is the great enemy of a person (Oh my god, I am saying like a Saint. )
>For example, generally how many databases MNC's manage per project
All it depends upon nature of application and number of users. As such, neither there is a formula nor you have to think for it. You should not bother how many DBAs are there in a DBA team of a company. Project manager and HRs knows what and how you are doing. Generally, there is one database is more than enough for an application, but all it depends upon SLA (Service Level Agreement) with clients of the company.
>If you are a experience holder could anybody plz share their experience on projects..
I am also a fresher, but don't thinks about those questions which are not relevant to my career or which may mis-guide me.
This really is site-dependent. Some people divide databases into different types, such as data warehouse (DW), online transaction processing (OLTP), decision support services (DSS), heterogenous (a mixture of those) and so on. For each of those, applications are going to have load profiles based on the querying and updating involved. Hopefully, an OLTP system will have many short quick transactions, while a data warehouse may have huge data loads followed by some number of massive queries, and a DSS system may have to account for a wide variance of queries.
Billy was giving an example of two extremes, I suppose to illustrate that you have to apply some empirical observation to answer questions like "how big should the sga be?"
Some people expect formulae to be given by vendors to figure out these things. That may be a bit too much to expect, unless the vendor has a large number of customers with similar load profiles. It can be calculated, but you still have to understand the application to do that (google Shallahamer forecasting), and even if you get the approximate size right, you still need to test empirically under typical application loads, and even after that, things change in production - to be more accurate, DBA's will have to spend a lot of time on plan maintenance. You can let Oracle figure it out, and then just react to problems. You can follow some guidelines (like using hugepages, or not). There is such a wide range of solutions, all a fresher can do is learn from experience, go to conferences, and try to follow the issues online.
TIMTOWTDI - There Is More Than One Way To Do It.