Database tuning (1.5 TB DB)
Good morning everybody,
soon our Pega database, running Oracle version 12.1, will probably reach 1.5 TB.
We wonder if we can improve its manageability, and we have some questions for you:
- are there some PDFs or documents related to Best Practices or Recommendation in case of very large Pega's Oracle databases (1 TB or more)?
- Is anybody managing an Oracle DB so large? If so, are you following additional guidelines?
- does anybody think that it is correct to have some tables (and some of their indexes) in the range of 100 - 200 GB, which are not partitioned?
- Is it correct that we have just one tablespace (whose 50 datafiles will sum up almost 1.5 TB) which contains all together : tables, indexes, BLOBS?
- Can anybody confirm if the following BLOB's parameters (either for performance or for storage utilization ) : "IN ROW", "NOCACHE", "CHUNK 8192" (this one is probably ignored), no PCTVERSION, no RETENTION are correct?
Also, we are concerned about BLOB data. There are 4 tables, which are clones of PC_WORK where we store our service cases/interactions specific for each application, whose BLOB segments (all using new SECUREFILE option) will be 100 GB soon.
I would really appreciate if I could get some inputs on these questions to improve the performance of our DB and the space management.
Thank you very much,
Víctor
Pegasystems Inc.
IN
Hello
This article on PDN can help here.
However I encourage you to take inputs from DBA and project Pega LSA of the project for this .
Pegasystems Inc.
IN
1) can you kindly check the this below link for the Best Practices Recommended in case of very large Pega's Oracle databases
https://docs-previous.pega.com/performance-guidance-production-applications-database.
2)does anybody think that it is correct to have some tables (and some of their indexes) in the range of 100 - 200 GB, which are not partitioned?
no that would not be a recommend practice.
3)Is it correct that we have just one tablespace (whose 50 datafiles will sum up almost 1.5 TB) which contains all together : tables, indexes, BLOBS?
We genrally doesnt prefer to use one table space for that large database we recomeed to use mutilple table spaces