Re: Shared memory error
Date: Mon, 10 May 2021 23:06:04 +0530
Message-ID: <CAEjw_fhbcKSm+h0hDTMLmZm03rPw-aB8gCOLMHgTOsXgDK2pcQ_at_mail.gmail.com>
Yes DATA and RECO were the same physical devices. Its X5 machine. But the theory behind the cause of slowness , is that it appeared that the DATA disc group was facilitating flash cushion for the UNDO read and write and again it was write back enabled here, so it was giving better response. And perhaps the same was the case in case of temp read and write too. But when we moved to RECO there was no flash in picture for the UNDO/TEMP read and write , so we basically got the pure hard disk response after moving to RECO so the slowness occurred. After rolling back that change , we are seeing normal performance as we used to see in the past.
Regards
Pap
On Mon, May 10, 2021 at 6:07 AM Mladen Gogala <gogala.mladen_at_gmail.com> wrote:
> There is also the question of hardware. Are the +RECO and +DATA disk
> groups comprised of different physical devices on different controllers
> or did you just ask your storage admin for some SAN storage and created
> disk groups from that? If the same physical disks are used for both disk
> groups, the logical separation will not help you much. Problem with the
> traditional SAN is that it obscures the connection between the actual
> physical disks and LUN devices. Actually, SAN is like a box of
> chocolate, you never know what you'll get.
>
> Of course, the new generation of SSD SAN devices like XTremIO or Pure
> deals with that by having much faster disks with much greater
> throughput. As for the shared memory error, set the shared_pool_size in
> the spfile and Oracle will not go below that. Figure out how much do you
> need to keep everything what you need in the shared pool and set the
> parameter in spfile.
>
>
> On 5/5/21 7:47 AM, Pap wrote:
> > We have recently created a new UNDO tablespace on RECO tablespace
> > because of space crunch on DATA disk group. So basically all the DML
> > and everything happens on DATA whereas UNDO sits on RECO, so can it be
> > the cause of such issues anyway?
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
> https://dbwhisperer.wordpress.com
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon May 10 2021 - 19:36:04 CEST