Hi Cringer,
I am already in the process of going for a training on progress DBA. But no facility in ASIA....
Thanks a lot for your explanation...
Thanks and Regards,
Surya
Hi Cringer,
You are correct. I have just started learning more about progress. I am an Oracle DBA and taking up Progress DBA role also. This is the first time that I ever went into more details about how BI clusters are assigned and reused.
BTW, we are using 10.2A3 in RHEL 5.8. Recently we...
Hi Cringer/RealHeavyDude/Fitz,
Thanks a lot for your information.
We are actually performing huge loading transactions. We did a series and test and the conclusion is that BI cluster was unused due the very first cluster being active. It was interesting to see that after the first...
Hi All,
We are performing bulk loading and the BI is getting increased in uncontrolled way.
Any solution to restrict BI growth?
Thanks and Regards,
Surya
Hi Tom,
We increased -B from 35000 to 50000 to one of 120GB database and the buffer cache hit increased from 90% to 95%. We will monitor for sometime and increase to 75000.
Thanks and Regards
Hi Tom,
The free memory kept reducing on non patched environment while it remained same in patched environment in the promon output.
Tomorrow we are going to production change.
Thanks
Hi Tom,
Yes. I tested before and after patch and also in patched and non patched environment. I used promon option R&D followed by 1 and 14 options. The shared memory segment reduced each time there was a disconnection in non patched environment but the shared memory remained constant in case...
Hi Tom,
We created concurrent remote connections and checked shared memory that remained constant after Patch apply which is not the case before patch apply. This lead us to that the memory leak is resolved.
If the issue still happens with -Mxs, we will get application team to involve in...
Hi Tom,
The gradual change is to first see how it impacts. We do have some DBs with 99% hit with 35000 setting. I will definitely follow your suggestion.
Thanks a lot.
Hi All,
Thanks a lot for all your information. We applied 10.2A03 SP and the shared memory leak is resolved. So in order to isolate the root cause we are following below:
1. Apply SP 10.2A03.
2. Start watchdog.
3. Monitor for one month if the issue repeats.
4. If issue repeats, Use -Mxs 512...
Hi Tom,
Well, no performance issue reported as of now and could be due to SSD disks we are using. But my plan is there already to move in grdual steps. -N From 35000 to 50000 to 75000 to 100000 and so on until above 97%.
Thanks a lot for your information..
Hi Rob,
You are right! We are setting parameters in development to check if additional memory will be required. Stress rest is in progress...
I will update last production parameters later today.
Thanks
Hi Tom,
This is from test where we just started to tune. -B is 35000 and cache hit is 90% in production. We want 95% and more so we are increasing to 50000 first and see the difference.
Runaway users are those which we see at OS level but unable to connect to database. Runaway is experienced...
Hi TheMadDBA,
Thanks a lot. I will increase -L to 100000. Also will update once patch has been applied...
BTW, I believe the issue will still be there due to inefficient application coding by developers. As a DBA I am clearing my area to isolate the issue,,,
Thanks...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.