Re: Database Appliance

  • From: Jack Applewhite <jack.applewhite@xxxxxxxxxxxxx>
  • To: "Clay Jackson (cjackson)" <Clay.Jackson@xxxxxxxxx>, Jeff Chirco <backseatdba@xxxxxxxxx>, oracle-l-freelist <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 3 Feb 2021 16:43:34 +0000

Clay,

I've not heard that before, but we have no REDO issues at all. Really no I/O 
issues at all, and we do have some pretty massive DML going on in the DBs on 
the X8s. Our problem is Vendor-written or our own Developer-written SQL that's 
just bad or doesn't scale up from their simple test cases. Worst ones have 
Explain Plan Costs of 10s or even 100s of Billions. I do a lot of session 
killing. "It's good to be King."
--
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: Clay Jackson (cjackson) <Clay.Jackson@xxxxxxxxx>
Sent: Wednesday, February 3, 2021 10:20
To: Jack Applewhite <jack.applewhite@xxxxxxxxxxxxx>; Jeff Chirco 
<backseatdba@xxxxxxxxx>; oracle-l-freelist <oracle-l@xxxxxxxxxxxxx>
Subject: RE: Database Appliance

Warning: EXTERNAL SENDER, use caution when opening links or attachments.



Hi, Jeff and Jack –



I’ll admit, I’ve been out of the hardware arena for a while now;  but one of 
bits of “conventional wisdom” that I recall is that “SSD is not recommended for 
write-intensive operations”.  Are you seeing any performance issues with your 
redo?



Thanks!



Clay Jackson





From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> On Behalf 
Of Jack Applewhite
Sent: Wednesday, February 3, 2021 7:43 AM
To: Jeff Chirco <backseatdba@xxxxxxxxx>; oracle-l-freelist 
<oracle-l@xxxxxxxxxxxxx>
Subject: Re: Database Appliance



CAUTION: This email originated from outside of the organization. Do not follow 
guidance, click links, or open attachments unless you recognize the sender and 
know the content is safe.



Jeff,



We love these X8s now that we've learned more about them and multitenant. The 
best part is 100% SSD storage - no more I/O bottlenecks at all. Choosing ASM 
instead of ACFS like we originally had to do with our X5s and going Bare Metal 
instead of Virtualized are the next two very good things. Our management 
hamstrung us a bit by only getting them with the minimum 12 TB raw storage each 
- 6 TB mirrored. We need more and may get it later this year. We're very happy 
not to have to deal with the HA layers on these X8s. We've never done RAC and 
never will.



Oracle Techs botched the initial install of ODA version 18.7, so I learned how 
to reimage and patch the things. Our SysAdmin created a VMWare Ubuntu Linux VM 
for me and installed the Iced Tea utility that allowed the ILOM remote console 
to run in it. That makes it where I could do all the reimaging, patching, etc. 
remotely - no trips to the data center.



I got both X8s to the 18.8 ODA version, then migrated several Production 
11.2.0.4 DBs to 18.8. Prior to this we had zero experience with multitenant, 
having passed on upgrading to 12c all these years. If you're on 12c and know 
the architecture, you'll be in good shape. Over our Thanksgiving and Winter 
Breaks I patched us up to 19.6. Once we address a minor issue I encountered, 
I'll patch up to 19.8, where we'll stay for a good while.



In the Fall I reimaged one of our X5s to 19.8 Bare Metal and ASM so we could 
migrate 11gR2 DBs off our old X4s and retire them. We're still migrating DBs 
from them to this X5.



It's too much right now, but I'd be happy to share my experience with which 
utilities work best under which circumstances - odacli, odaadmcli, dbca, dbua, 
BUI, EM Express, etc.

--
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: Jeff Chirco <backseatdba@xxxxxxxxx<mailto:backseatdba@xxxxxxxxx>>
Sent: Wednesday, February 3, 2021 09:10
To: Jack Applewhite 
<jack.applewhite@xxxxxxxxxxxxx<mailto:jack.applewhite@xxxxxxxxxxxxx>>; 
oracle-l-freelist <oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>>
Subject: Re: Database Appliance



Warning: EXTERNAL SENDER, use caution when opening links or attachments.



Hi Jack its been a year now with your new ODA X8-2Ms and I was wondering what 
your thoughts are?  How has patching been? We are considering a 2M and a 2-HA 
model, however the HA model will not be used for RAC. Everything will be a 
single instance.

I would love to hear your thoughts. This is a big decision for us. Currently we 
are on small 4 CPU Dell servers. Everything is going well but we need to up our 
CPU count and a storage refresh is on the table as well, currently we have 
NetApp.  Storage Admins want to move off NetApp so the ODA sounds appealing.



Jeff



On Thu, Nov 28, 2019 at 8:06 AM Jack Applewhite 
<jack.applewhite@xxxxxxxxxxxxx<mailto:jack.applewhite@xxxxxxxxxxxxx>> wrote:

We loved, loved, loved our X4 and X5 ODAs for a good while. Great integrated 
package of host, storage, OS, CPU, memory, etc. for a good price. We did not 
and will not use them or any machines for RAC, so all the HA and Grid pieces 
were a nuisance, becoming a nightmare when applying the ODA patches. If 
something gets misaligned, the house of cards tumbles. We've still got 
persistent problems with one X4 and one X5 that Oracle Support can't help with 
- all due to the Grid pieces. Now we hate, hate, hate those ODAs.



However, we're getting two new machines and, guess what, they're ODAs. The 
difference this time is that they're X8-2Ms, which have zero Grid and RAC 
built-in stuff. They're just SSD storage, memory, and CPU. We'll get them 
installed Bare Metal with 19c. They are a well-priced package and we're hoping 
easier to support and patch, given their simpler configuration.



So, in a couple months I'll be able to report on how they are treating us.

--
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@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx
<oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>> on behalf 
of Mladen Gogala <gogala.mladen@xxxxxxxxx<mailto:gogala.mladen@xxxxxxxxx>>
Sent: Wednesday, November 27, 2019 17:13
To: oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx
<oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>>
Subject: Re: Database Appliance



Yes, both Upendra and Andy are correct. You don't want an ODA. I too have some 
horror stories from my tenure at Commvault, but a NDA prevents me from sharing 
anything.



On 11/27/19 1:57 PM, Upendra nerilla wrote:

If Andrew's stores aren't enough and if you want more.. PM me.. ??





________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx
<oracle-l-bounce@xxxxxxxxxxxxx><mailto:oracle-l-bounce@xxxxxxxxxxxxx> on behalf 
of Andrew Kerber <andrew.kerber@xxxxxxxxx><mailto:andrew.kerber@xxxxxxxxx>
Sent: Wednesday, November 27, 2019 1:46 PM
To: jreid@xxxxxxxxxxxxxxxxxx<mailto:jreid@xxxxxxxxxxxxxxxxxx
<jreid@xxxxxxxxxxxxxxxxxx><mailto:jreid@xxxxxxxxxxxxxxxxxx>
Cc: ORACLE-L <oracle-l@xxxxxxxxxxxxx><mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Re: Database Appliance



1. You do not want an ODA.

2. You do not want an ODA.

You can PM me for horror stories.



On Wed, Nov 27, 2019 at 12:40 PM Joseph Reid 
<jreid@xxxxxxxxxxxxxxxxxx<mailto:jreid@xxxxxxxxxxxxxxxxxx>> wrote:

Hi all,

is there a tool/script to do a assessment for the Oracle Database Appliance? We 
need help in determining  our requirements as to what size of Database 
Appliance would be needed.

Thank you,

Joseph Reid






--

Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

--

Mladen Gogala

Database Consultant

Tel: (347) 321-1217

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.

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.

Other related posts: