Re: Oracle ODA suggestions.

Ok well actually we typically have a standard 3-4 hour window once a month for any maintenance activity. For my 19c upgrade I got a longer window. However if any database/server/storage is not up by 7am we are in trouble. We have a Data Guard setup but that is kind of a last resort, there will possibly be some other issues if we had to use it. It's there for a true disaster situation, at least we have the data.

On Wed, Mar 31, 2021 at 8:37 AM Jack Applewhite < jack.applewhite_at_austinisd.org> wrote:

> Jeff,
>
> Wow! I'm envious. You get flawless patching in an hour or less? From whom?
> That's great.
>
> When I said "most of the time", I think I was averaging in all 7 years'
> worth of ODA patching together. If I consider only the 18.x and 19.x ones
> in the last year, I'd have to say "nearly all the time". Sadly, many of the
> glitches we've encountered are due to us not reading all the Known Issues
> of every intervening patch from where we're coming from to where we're
> patching to. We usually like to stay behind the "latest and greatest" to
> avoid Bleeding Edge issues. Then we'll skip a couple releases to get a
> little less behind. Us re-imaging an X5 to 19.8 shortly after it was
> released was uncharacteristically bold of us. However, we knew that ODA
> would only host Dev and Test DBs and we could have it down longer than if
> it was for Prod DBs.
>
> Yes, I've gotten some bozo Oracle Support techs who really didn't know
> ODAs well enough, but mostly I've gotten knowledgeable and effective ones.
> YMMV. Getting bozos for Support has been my experience with just about
> everything, not just Oracle.
>
> The longest downtime for a patch was the one - I forget exactly which -
> that took the OS from OEL 6.x to 7.x. It was several hours. However, a Sys
> Admin in our org. said he had an equally long struggle with a Dell server
> going from RH 6 to 7. So, the big Linux upgrade was problematic no matter
> the platform.
>
> There's also the "stay with the devil you know" comfort factor. We're
> familiar with the ODAs, warts and all. With the new X8s we find many fewer
> warts and a Lot more to love. We even like our X5, now that it's at 19.8.
> Still don't like the other X5 that's stuck at ODA 12.2.0.4 (I think), but
> that's another story.
>
> Happy server hunting!
> --
> Jack C. Applewhite - Database Administrator
> Austin I.S.D. - MIS Department
> 512.414.9250 (wk)
>
> I cannot help but notice that there is no problem between us that cannot
> be solved by your departure. -- Mark Twain
> ------------------------------
> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on
> behalf of Jeff Chirco <backseatdba_at_gmail.com>
> *Sent:* Wednesday, March 31, 2021 09:45
> *To:* Jack Applewhite <jack.applewhite_at_austinisd.org>
> *Cc:* oracle-l_at_freelists.org <oracle-l_at_freelists.org>;
> gogala.mladen_at_gmail.com <gogala.mladen_at_gmail.com>
> *Subject:* Re: Oracle ODA suggestions.
>
> Warning: EXTERNAL SENDER, use caution when opening links or attachments.
>
>
> I've been contemplating getting an ODA for a while, we've never had one
> but are in discussion of needing to upgrade our Dell hardware so it has
> been on the table. Here are my thoughts on a couple of your points.
>
>
> * -- We have "a single throat to choke" in Oracle being responsible for
> everything. No finger-pointing between Dell support and Oracle support.*
>
>
> I found this to be a negative. Oracle support has always been a pain to
> deal with. Occasionally you get a good one but more often responses take
> too long and they are usually asking dumb questions which halfthe time I
> already answered if they read the original problem description. If Oracle
> support was better then this might be a good point. I've also heard that
> there are not many ODA experts at Oracle support. I could be wrong.
>
> * -- Applying ODA patches upgrades all components to a compatible level -
> most of the time flawlessly.*
>
>
> The "most of the time" scares me. It should be every time. We are much
> more comfortable patching things individually. Storage and server guys know
> their stuff and I know database stuff. We don't over step each other. I
> have heard horror stories of an ODA being down for hours or a full day
> because a patch went wrong. I don't know what people are running on these
> things but we can't be down like that for more than an hour. I also have
> root on the server and take care of some things myself.
>
>
> On Wed, Mar 31, 2021 at 7:23 AM Jack Applewhite <
> jack.applewhite_at_austinisd.org> wrote:
>
> Mladen,
>
> From a strictly hardware standpoint, you're probably right. However, the
> bottom to top integration of HW, Infrastructure, OS, and RDBMS is Very
> handy.
> -- We have "a single throat to choke" in Oracle being responsible for
> everything. No finger-pointing between Dell support and Oracle support.
> -- Applying ODA patches upgrades all components to a compatible level -
> most of the time flawlessly.
> -- We can usually use MOS notes and docs to troubleshoot errors and
> problems at all levels.
> -- As Andrew mentioned, the ASR feature is Very useful. We've gotten
> notice that Oracle has already shipped a new drive, fan, power supply, etc.
> to us before we were even aware of the failing component.
>
> These new Bare Metal X8-2Ms, without the RAC, virtualization, and ACFS
> crap, are the best packages we've ever had. Plus, we get to be root and
> mostly manage them ourselves, which may not be an option in a lot of shops.
>
> That's my story and I'm stickin' to it. Happily.
> --
> Jack C. Applewhite - Database Administrator
> Austin I.S.D. - MIS Department
> 512.414.9250 (wk)
>
> I cannot help but notice that there is no problem between us that cannot
> be solved by your departure. -- Mark Twain
> ------------------------------
> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on
> behalf of Mladen Gogala <gogala.mladen_at_gmail.com>
> *Sent:* Tuesday, March 30, 2021 21:18
> *To:* oracle-l_at_freelists.org <oracle-l_at_freelists.org>
> *Subject:* Re: Oracle ODA suggestions.
>
> Warning: EXTERNAL SENDER, use caution when opening links or attachments.
>
>
>
> Hi Jack!
>
> What is the difference between a big Dell box with many cores and NVME
> drives and ODA? What you are describing sounds like a very big and fast
> PC with Linux and Oracle per-installed.
>
> On 3/30/21 4:59 PM, Jack Applewhite wrote:
> > Our X8s are Bare Metal, single server machines with 100% SSD storage
> > and a joy. After I re-imaged them to 18.8, patching to 19.6 presented
> > a few problems. mainly going from OEL 6 to 7, but, with Oracle
> > Support, we worked them out. We are very happy with 19.6 ODA version
> > and RDBMS version.
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
> https://dbwhisperer.wordpress.com
>
> --
>
> https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.freelists.org%2fwebpage%2foracle-l&c=E,1,7oEmWw3NZnzMfLDh1j5rp07U5pAf-X7k2R18tnrfxJ3qOX-41XGAzmK51BQqaA2yUxbT4EuveYpHyU6_6DU2HFv85P7KcthKvxlF9Q_s&typo=1
>
>
> Confidentiality Notice: This email message, including all attachments, is
> for the sole use of the intended recipient(s) and may contain confidential
> student and/or employee information. Unauthorized use of disclosure is
> prohibited under the federal Family Educational Rights & Privacy Act (20
> U.S.C. §1232g, 34 CFR Part 99, 19 TAC 247.2, Gov’t Code 552.023, Educ. Code
> 21.355, 29 CFR 1630.14(b)(c)). If you are not the intended recipient, you
> may not use, disclose, copy or disseminate this information. Please call
> the sender immediately or reply by email and destroy all copies of the
> original message, including attachments.
>
> Confidentiality Notice: This email message, including all attachments, is
> for the sole use of the intended recipient(s) and may contain confidential
> student and/or employee information. Unauthorized use of disclosure is
> prohibited under the federal Family Educational Rights & Privacy Act (20
> U.S.C. §1232g, 34 CFR Part 99, 19 TAC 247.2, Gov’t Code 552.023, Educ. Code
> 21.355, 29 CFR 1630.14(b)(c)). If you are not the intended recipient, you
> may not use, disclose, copy or disseminate this information. Please call
> the sender immediately or reply by email and destroy all copies of the
> original message, including attachments.
>

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