Do general purpose or OLTP Oracle databases really perform better on SPARC based servers?
Does running Oracle 11g and 12c databases under OLTP type workload on SPARC architecture really offer performance benefits compared to a similar specification Intel based server (keeping the Core-count same to remove the licensing from the picture)?
Hi,
The answer for your question is a simple: yes, it performs better on the same configuration memory/cores. The reason is simple: sparc performs much better than intel, and the architecture designed by oracle to get the most of their processors it is really good. Besides, using red hat as a SO, on intel processors, the gap is shorter. But the winner is SPARC.
Search for a product comparison in Relational Databases Tools
Database Senior Manager at a financial services firm
Vendor
2017-10-30T10:51:28Z
Oct 30, 2017
In my experience SPARC provides far better performance than x86 based server. Databases are more responsive and way quicker to start. Recently, I had the privilege to run 70(Yes, 70) databases on a single E25k SPARC server with around 256GB RAM. No issues whatsoever. Try running half of that on a x86 based server and it would be a disaster. Having said that, I am sure you must have read that Oracle has stopped further development of SPARC which indirectly means that it will stop SPARC sooner rather than later. Would you still want to use/move to SPARC servers?
Technology Director at a insurance company with 501-1,000 employees
Real User
2017-11-05T18:01:57Z
Nov 5, 2017
Yep. But oracle shutdown sparc os. So that means oracle linux on intel
architecture is inevitable. There may be some trade-offs of course :
- sparc admins vs linux admin cost
- sparc performance vs oracle performance optimizations
OpenVMS Programmer/Developer (Itanium2) at Bell Canada
Real User
2017-10-31T18:27:09Z
Oct 31, 2017
Many companies are replacing SPARC (32-bit) and UltraSPARC (64-bit) hardware with x86-64 thinking they can just emulate the older stuff. But this usually fails. That's when the young kids learn that the older SUN architecture was doing something quite different (eg. Solaris on SPARC was a really fast thread dispatcher)
Principal Database Administrator at a pharma/biotech company with 10,001+ employees
Real User
2017-10-31T15:33:13Z
Oct 31, 2017
The answer is it depends on your implementation details. Here is the best article I could find on the subject that explores the latest information Oracle has provided on on S7 vs Xeon. https://www.nextplatform.com/2016/07/21/stacking-oracle-s7-intel-xeon/ For most OLTP users the answer is definitely No! but there are a certain group of users at the high-end that are using the in-memory database in combination with analytics that might find the chipset a better solution due to the special database operations encoded on the silicone. You should always test your workload on the two systems you are comparing before making a large buying decision. Excerpt from the excellent article: " The message from us when looking at all of these numbers is the same as you will always hear from us: These metrics and measures are a good place to start, but you always have to do your own benchmarking and your own economic analysis based on your own applications and the configurations needed to run them well. None of this is ever as cut and dry as it looks in the benchmarks."
SPARC based servers perform better especially when dealing with heavy workloads, the OS also matters, UNIX/Solaris will give you better and reliable performance
Sr Solutions Architect at a tech services company with 1,001-5,000 employees
MSP
2017-10-31T13:43:02Z
Oct 31, 2017
There’s really two questions. Does SPARC — or possibly other UNIX based CPUs and OSes — actually allow Oracle to perform better, and will you see meaningful improvements that, based on your budget, environment, and needs, show you improvements that are worth the cost difference as compared to an x86 server environment? The SPARC based servers definitely show greater performance with OLTP workloads as compared to Intel or AMD based servers. IBM POWER processor baser systems show even greater gains. I’m honestly less familiar with HP-UX systems, and cannot comment accurately on them. True UNIX OSes typically offer greater stability as compared to Linux and increased performance due to deeper and more narrow integration with the processor and other hardware.
Linux is a well established OS, and very reliable for running Oracle DBs. Oracle’s claims about OEL aside, I have never been able to prove any superiority about OEL vs RHEL or other variants in real world scenarios. I’ve been working with Oracle for 20 years as of this past summer, and spent a couple of years working with Linux kernel developers at IBM testing SMP scalability with Oracle and RAC environments on Linux a little more than 10 years ago. If you’re comfortable with SPARC and SOLARIS, great. There’s nothing wrong with it. If you want to look at ways to lower your ongoing costs, and are comfortable with Linux or with the idea of exploring it, then I would highly recommend exploring possibilities across the major x86 vendors. Cisco, HPE, and Lenovo have deeper backgrounds with memory subsystem development than does Dell, and so I would lean toward one of them, but then it’s a matter of choosing your favorite flavor of ice cream, because all flavors of Linux are Linux. Just choose one with a good support structure that is supported on the HW platform you choose. If you are averse to change, and the extra cost is not an issue for you, then staying where you are fits with the, “it it ain’t broke, don’t fix it” mantra, and is perfectly valid.
Director of Information Technology at a tech services company
Real User
2017-10-31T11:46:19Z
Oct 31, 2017
Running Oracle DB on Sparc offers better performances for sure.
This is due to the kernel used.
In fact, Sparc with Solaris is much much reliable/robust than x86 and Windows.
Solaris (as all Unix systems) has a better Memory and Thread management and offer better performances because of that.
On the other hand you have to take TCO intp the equation and then you might have to choose Windows.
I have just completed the Infrastructure Architecture and RoadMap for our Oracle DB and Fusion platforms.
We will go with 10 Oracle SPARC S7-2L servers for DB with 12 NVMe flash disks and SAN connection and 1 TB of memory, and 8 SPARC S7-2L servers for Fusion and other applications servers.
The reason we go with these servers are driven by TCO, Performance and flexibility (especially Hard partitioning)
One internal concern was Vendor Lockin, and it took me some time and energy to make Business understand that the Vendor Lockin is at the Platform level(Oracle DB) and not the Infrastructure level (SPARC and Solaris)
SPARC is RISC, yes, but SPARC uses register windows. Register windows are essentially an architectural relic - they don't really help performance these days, and in fact make implementation of out-of-order execution difficult.
1. Keep same memory
2. Keep same I/O response
3. Count total threads between x86 and SPARC
4. Keep in mind x86 has 0.5 multiplying factor
5. Identify SPARC multiplication factor
6. Thus for same processor license you can compare x86 and SPARC - ensuring apples to apples comparision
Vendor lock-in is a big issue with Oracle, and using Sparc based servers just feeds into this. If you want to be flexible while getting desired performance, then go with Xeon based server option which would give you lot more options. Backup, recovery and scalability by adding more servers is often less costly when you go with Xeon based servers as compared with Sparc based servers.
In my experience, we got excellent performance with Solaris and Oracle 11g plus Xeon based servers. We also had servers with Windows which were much slower and difficult to optimize as compared to Solaris based servers.
Hi,
Oracle keep investing its Engineering Systems (Exadata, see https://www.oracle.com/engineered-systems/index.html) based on INTEL. The best performance they gain is on this hardware.
I would not gamble a dead horse.
Definitely Oracle solutions are bound to provide better performance on SPARC architecture machines. The performance numbers published in the Oracle site vouch for that
e-Learning Systems Developer Analyst at a university with 1,001-5,000 employees
Vendor
2017-10-30T22:50:47Z
Oct 30, 2017
If you really need a lot of parallel query processing, having a real multithreading controller for your database, a Sparc S7 processor gives 8 threads per core, where Intel cores have 2 threads per core. Both mostly use RISC architecture, and there is a price difference.
If you have your CPUs capacity on average more than 70% at all times, you may need to consider more cores, the bandwidth of both systems are of equal performance, just the memory support is higher for the Sparc S7 systems.
Cost per CPU is a measure valid only on high capacity utilisation, so you do not buy processors just because they are cheap or … cheaper than … just measure the requirements on average and the critical bottleneck or negative impact on spikes of demand, and if the cost of losing income or compensations expenses are higher than the cost of extra capacity, then it is a must to have it.
Oracle database servers, use background parallel tasks to keep up with predictive statistics of data tuples, so a demanding SQL server can consume all resources available if demanded. Just try to keep it within reasonable range of capacity.
Soooo, that's something everyone likes to speculate about from time to
time and after some 30+ years in this business I've seen a lot.
Let's start with a "how it works", the real simple version. Obviously
there can be a lot more done, but it's basically this.
-When someone submits a query against a database server, it parses the
query, selects the tables and the indexes that favor the join between
tables of data to use the "relation" of the relational database (if
there is more than one table selected), the columns that are requested
and used to filter the results, executes the data retrieval, filters it,
orders it (using a index when possible or needed) and sends the data
back to the client.
Essentially that's it.
It's not so much about data processing, but data reading, joining,
sorting, filtering and sending everything through the wires to the
requester. To be able to do this quickly, the server needs a couple of
things:
- RAM memory : to create temporary areas to select/apply filters/order
the data.
- Hard disks : essentially where the data is stored.
Now, remembering computer class 101, RAM is very fast compared to hard
disks. Even the slowest RAM is still very fast to *most* hard disks.
Hard disks need to read the file allocation table (FAT, NTFS, whatever)
to know where is what on the platters, position the reading heads to the
area, read the files that are written on the platters, puts it all
together and gives it to the server that's asking for that particular
piece of data. And the data is splattered accross the platters in a way
that almost allways it'll be possible to hear the heads frenetically
going back and forth if you put your head close enough to the hard disk.
So, after this description, it's easy to percieve that the most
important things for a database server are:
RAM - preferentially lots of it.
Hard Drives - the faster the better.
As SSD's are Solid Sate Drives, they have no moving parts, therefore the
read/write is REALLY faster.
IF, and that's a big if, the so mentioned SPARC based servers have
outstanding hard drives and RAM memory, I fail to see where it should be
faster that any other type of similar hardware. Of course, if you need a
lot's of data transformation that is done by the server application,
then the SPARC may be faster. Otherwise...
If possible test the machine using data and with a workload that would
be used in your day-by-day applications. Then you'll be able to see for
yourself if this specific hardware fills your computational needs.
Obviously, I am not considering things like MTBF of the machine,
redundancy of PSU and other parts like controllers and hard disks,
replication and loadbalancing of the data servers to support 24x7 uptime
if necessary and things that make most managers have nightmares... but
that's another story.
Comparing OLTP 11g/12c performance just at x86 vs SPARC will need to at least do following -
1. Keep same memory
2. Keep same I/O response
3. Count total threads between x86 and SPARC
4. Keep in mind x86 has 0.5 multiplying factor
5. Identify SPARC multiplication factor
6. Thus for same processor license you can compare x86 and SPARC - ensuring apples to apples comparision
7. If OLTP transactions are very small - it is possible SPARC may come out ahead, but then you are for sure ignoring cost $$ per GHZ etc
8. In short I can't say in $$ terms it will make sense as any additional memory, disk (and SSD specifically) will cost much more for SPARC compared to typical x86
9. Oracle engineered systems may come out ahead in $$/performance matrix given budget constraint
Consulting Chief Scientist TS/DoD at a tech vendor
Vendor
2017-10-30T16:01:54Z
Oct 30, 2017
https://blogs.oracle.com/bestperf/simultaneous-oltp-in-memory-analytics:-sparc-t7-1-faster-than-x86-e5-v3
I am not surprised, here are some testing results Oracle published
Owner at a tech consulting company with 1-10 employees
Consultant
2017-10-30T15:46:35Z
Oct 30, 2017
A lot of this depends on your application. On average, x86 will hold it own against SPARC, other than in possibly unique environments. Biggest positive about x86 is multiple sources and the ability to grow horizontally at a much lower cost than SPARC. Let alone that SPARC will become obsolete in the not too distant future, in which most likely move will be to x86, so why not move now. Moreover, if there is a potential that you could move to the cloud, you will have better options with an x86 base than a SPARC base.
Telecommunications Engineer at a comms service provider with 1,001-5,000 employees
Real User
2017-10-30T13:36:21Z
Oct 30, 2017
According to the experience in the company I work for, the "general purpose" and DSS/DWH perform better on Intel. I guess it's all about the application you run (and ours is quite heavy and complex), however in our case x86 deals better. We have about 512G of RAM, 128 CPUs (Intel(R) Xeon(R) CPU E7-8867 v3 @ 2.50GHz), running RHEL 6.7 and about 30Tb fiber IBM storage.
This is a Cloud implementation? I know Spark can be used on premise and without Hadoop but have not seen it done.
The decision here has been not to move ORACLE to the Cloud where we will use HORTON Works (Spark) on top of a Hadoop cluster. We are looking at Amazon. We are starting proof of concept testing with Amazon. The primary driver is a much reduced cost if we use Spark which should be faster as it is all in memory. The IO being the pain point for most processing.
I expect the best performance in CLOUD for ORACLE would be on the ORACLE Cloud so the specific Cloud environment would be an issue. It would also depend on if your application software is Spark compatible. Python and R seem to work very well older languages that require wrappers, not so much. The other issue being the performance advantages depend on the size of the data, the Hadoop is best leverage with large data sets. You would likely seen little or no gain with smaller data sets.
Testing shows that reading and loading data are very fast compared RDMS systems the problem is with Updates.
We are still testing options. Data Bricks or SAS Viya gives even better performance gains than Spark but are licensed products.
Manager DBA at a healthcare company with 1,001-5,000 employees
Real User
Top 10
2017-10-30T13:23:29Z
Oct 30, 2017
I agree with Bobin about SPARC is much better than x86.
I am running 42 dev databases on my x86 server and I don't find that working excellent although I have 256GB memory and 48 cores on the box.
However since SPARC is going to be obsolete soon, I would keep my systems on intel to be on supported hardware.
Also If I am not wrong, support cost for SPARC is higher too.
I will echo Bobin's observations re: Oracle stopping development. I think the key is to look at the price drops in high-end hardware, and scale out on a 1.5x ratio if migrating from SPARC to x86. Also, look at virtualization low-churn loads, and segment your database stores based on usage analytics and HA services.
I work for a healthcare company with less than 1,000 employees.
I am new to FileMaker Pro but my company uses FileMaker Pro (FM Pro) as the frontend development tool. More and more applications will be built using FM Pro.
In the long run :
1. Is FM Pro Embedded DB or MS SQL Server a better choice in the long run for the backend database?
2. What are the pros and cons of using these two d...
Senior Database Consultant at Performing Databases
May 11, 2020
I have no experience with FileMaker, so I can't answer any FileMaker specific questions. But I am into the database business for a long time, so maybe I can help out at this point.
If you are asking for long term solutions and looking at the technology side, one of the big vendor databases (Oracle, Microsoft, IBM...) will be way better. This comes from rock-solid backup and recovery strategies, scalability, advanced-cache recovery strategies, and, not at least, widely available knowledge. Knowledge is coming from a huge hit list on the internet and from people like me and my colleagues all over the world. With a small vendor's specific database, this may be harder, if not impossible. A quick read showed me that even FileMaker themselves suggest storing container data outside the embedded system, due to the risk of data loss. For larger environments, with concurrency, Oracle for sure is the best possible solution. But it may be a bit harder to get it to work, but as soon as it works, it's rock solid. MS SQL makes your initial life easier, but in the long term, it allows you to make many mistakes and not recognizing them until it is too late.
Going for one of the big vendor databases has a downside: It introduces you to the big and ugly world of licensing. Using world-class features and having to pay for them is ok, but the issue is the terms of licensing. They vary widely, depending on the vendor, product, edition, and, the worst part, your internal infrastructure. Especially CPU based licensing in combination with current virtual environments can be challenging. User-based models, or working with Client Access Licenses (CAL) also has its pitfalls. As I said, it's not nice. But it is important to stay clean at this front. For a tease, as long as you stay small, vendors like Microsoft and Oracle (not sure with IBM) also offer free editions of their products, with limited sizes/resources, but with a large and valuable technology stack.
Going for free technology? I'd always recommend PostgreSQL then. PGSQL is not as scalable as Oracle is, but if you don't need much click-and-play stuff, it gives you most of what MS SQL would also bring. But when reading through FileMaker's web page, I can see you need an "Actual Technologies Adapter", no clue if this has any downsides.
One thing for sure: A database is no playground if you have important data to store. Make yourself familiar with the technology, or ask for educational support early in the process, to avoid long-term mistakes. People like myself are offering all kinds of help, from a free response in mailing lists up to on-site hands-on training.
Lavanya,
What is the context for comparison? Are you trying to compare performance in relation to a specific hardware configration? As John pointed out, you are kind of comparing apples and donuts, unless you have a specific use-case that can provide more detail for the comparison. Hana may, in some environments, replace the role a SQL server is holding, particularly if the SQL server is a data bridge, but you need to get way more specific in the ask.
Hi,
The answer for your question is a simple: yes, it performs better on the same configuration memory/cores. The reason is simple: sparc performs much better than intel, and the architecture designed by oracle to get the most of their processors it is really good. Besides, using red hat as a SO, on intel processors, the gap is shorter. But the winner is SPARC.
In my experience SPARC provides far better performance than x86 based server. Databases are more responsive and way quicker to start. Recently, I had the privilege to run 70(Yes, 70) databases on a single E25k SPARC server with around 256GB RAM. No issues whatsoever. Try running half of that on a x86 based server and it would be a disaster. Having said that, I am sure you must have read that Oracle has stopped further development of SPARC which indirectly means that it will stop SPARC sooner rather than later. Would you still want to use/move to SPARC servers?
My experience is that long-term, Oracle OLTP databases run best on physical
Linux servers with high performance disk clusters.
Yep. But oracle shutdown sparc os. So that means oracle linux on intel
architecture is inevitable. There may be some trade-offs of course :
- sparc admins vs linux admin cost
- sparc performance vs oracle performance optimizations
Many cost risks can be hedged.
Many companies are replacing SPARC (32-bit) and UltraSPARC (64-bit) hardware with x86-64 thinking they can just emulate the older stuff. But this usually fails. That's when the young kids learn that the older SUN architecture was doing something quite different (eg. Solaris on SPARC was a really fast thread dispatcher)
The answer is it depends on your implementation details. Here is the best article I could find on the subject that explores the latest information Oracle has provided on on S7 vs Xeon. https://www.nextplatform.com/2016/07/21/stacking-oracle-s7-intel-xeon/ For most OLTP users the answer is definitely No! but there are a certain group of users at the high-end that are using the in-memory database in combination with analytics that might find the chipset a better solution due to the special database operations encoded on the silicone. You should always test your workload on the two systems you are comparing before making a large buying decision. Excerpt from the excellent article: " The message from us when looking at all of these numbers is the same as you will always hear from us: These metrics and measures are a good place to start, but you always have to do your own benchmarking and your own economic analysis based on your own applications and the configurations needed to run them well. None of this is ever as cut and dry as it looks in the benchmarks."
SPARC based servers perform better especially when dealing with heavy workloads, the OS also matters, UNIX/Solaris will give you better and reliable performance
There’s really two questions. Does SPARC — or possibly other UNIX based CPUs and OSes — actually allow Oracle to perform better, and will you see meaningful improvements that, based on your budget, environment, and needs, show you improvements that are worth the cost difference as compared to an x86 server environment? The SPARC based servers definitely show greater performance with OLTP workloads as compared to Intel or AMD based servers. IBM POWER processor baser systems show even greater gains. I’m honestly less familiar with HP-UX systems, and cannot comment accurately on them. True UNIX OSes typically offer greater stability as compared to Linux and increased performance due to deeper and more narrow integration with the processor and other hardware.
Linux is a well established OS, and very reliable for running Oracle DBs. Oracle’s claims about OEL aside, I have never been able to prove any superiority about OEL vs RHEL or other variants in real world scenarios. I’ve been working with Oracle for 20 years as of this past summer, and spent a couple of years working with Linux kernel developers at IBM testing SMP scalability with Oracle and RAC environments on Linux a little more than 10 years ago. If you’re comfortable with SPARC and SOLARIS, great. There’s nothing wrong with it. If you want to look at ways to lower your ongoing costs, and are comfortable with Linux or with the idea of exploring it, then I would highly recommend exploring possibilities across the major x86 vendors. Cisco, HPE, and Lenovo have deeper backgrounds with memory subsystem development than does Dell, and so I would lean toward one of them, but then it’s a matter of choosing your favorite flavor of ice cream, because all flavors of Linux are Linux. Just choose one with a good support structure that is supported on the HW platform you choose. If you are averse to change, and the extra cost is not an issue for you, then staying where you are fits with the, “it it ain’t broke, don’t fix it” mantra, and is perfectly valid.
Running Oracle DB on Sparc offers better performances for sure.
This is due to the kernel used.
In fact, Sparc with Solaris is much much reliable/robust than x86 and Windows.
Solaris (as all Unix systems) has a better Memory and Thread management and offer better performances because of that.
On the other hand you have to take TCO intp the equation and then you might have to choose Windows.
I have just completed the Infrastructure Architecture and RoadMap for our Oracle DB and Fusion platforms.
We will go with 10 Oracle SPARC S7-2L servers for DB with 12 NVMe flash disks and SAN connection and 1 TB of memory, and 8 SPARC S7-2L servers for Fusion and other applications servers.
The reason we go with these servers are driven by TCO, Performance and flexibility (especially Hard partitioning)
One internal concern was Vendor Lockin, and it took me some time and energy to make Business understand that the Vendor Lockin is at the Platform level(Oracle DB) and not the Infrastructure level (SPARC and Solaris)
SPARC is RISC, yes, but SPARC uses register windows. Register windows are essentially an architectural relic - they don't really help performance these days, and in fact make implementation of out-of-order execution difficult.
Yes, you will see different when you run Oracle on SPARC server.
1. Keep same memory
2. Keep same I/O response
3. Count total threads between x86 and SPARC
4. Keep in mind x86 has 0.5 multiplying factor
5. Identify SPARC multiplication factor
6. Thus for same processor license you can compare x86 and SPARC - ensuring apples to apples comparision
Yes. The performance is better. But if you consider TCO you might choose otherwise.
Vendor lock-in is a big issue with Oracle, and using Sparc based servers just feeds into this. If you want to be flexible while getting desired performance, then go with Xeon based server option which would give you lot more options. Backup, recovery and scalability by adding more servers is often less costly when you go with Xeon based servers as compared with Sparc based servers.
In my experience, we got excellent performance with Solaris and Oracle 11g plus Xeon based servers. We also had servers with Windows which were much slower and difficult to optimize as compared to Solaris based servers.
Hi,
Oracle keep investing its Engineering Systems (Exadata, see https://www.oracle.com/engineered-systems/index.html) based on INTEL. The best performance they gain is on this hardware.
I would not gamble a dead horse.
I recommend that you seek help at the Experts Exchange website which is www.experts-exchange.com.
Definitely Oracle solutions are bound to provide better performance on SPARC architecture machines. The performance numbers published in the Oracle site vouch for that
If you really need a lot of parallel query processing, having a real multithreading controller for your database, a Sparc S7 processor gives 8 threads per core, where Intel cores have 2 threads per core. Both mostly use RISC architecture, and there is a price difference.
If you have your CPUs capacity on average more than 70% at all times, you may need to consider more cores, the bandwidth of both systems are of equal performance, just the memory support is higher for the Sparc S7 systems.
Cost per CPU is a measure valid only on high capacity utilisation, so you do not buy processors just because they are cheap or … cheaper than … just measure the requirements on average and the critical bottleneck or negative impact on spikes of demand, and if the cost of losing income or compensations expenses are higher than the cost of extra capacity, then it is a must to have it.
Oracle database servers, use background parallel tasks to keep up with predictive statistics of data tuples, so a demanding SQL server can consume all resources available if demanded. Just try to keep it within reasonable range of capacity.
Isn't SPARC now an obsolete piece of hardware within Oracle?
Did you check the TPC-C website to check performance figures from an independent official site?
Soooo, that's something everyone likes to speculate about from time to
time and after some 30+ years in this business I've seen a lot.
Let's start with a "how it works", the real simple version. Obviously
there can be a lot more done, but it's basically this.
-When someone submits a query against a database server, it parses the
query, selects the tables and the indexes that favor the join between
tables of data to use the "relation" of the relational database (if
there is more than one table selected), the columns that are requested
and used to filter the results, executes the data retrieval, filters it,
orders it (using a index when possible or needed) and sends the data
back to the client.
Essentially that's it.
It's not so much about data processing, but data reading, joining,
sorting, filtering and sending everything through the wires to the
requester. To be able to do this quickly, the server needs a couple of
things:
- RAM memory : to create temporary areas to select/apply filters/order
the data.
- Hard disks : essentially where the data is stored.
Now, remembering computer class 101, RAM is very fast compared to hard
disks. Even the slowest RAM is still very fast to *most* hard disks.
Hard disks need to read the file allocation table (FAT, NTFS, whatever)
to know where is what on the platters, position the reading heads to the
area, read the files that are written on the platters, puts it all
together and gives it to the server that's asking for that particular
piece of data. And the data is splattered accross the platters in a way
that almost allways it'll be possible to hear the heads frenetically
going back and forth if you put your head close enough to the hard disk.
So, after this description, it's easy to percieve that the most
important things for a database server are:
RAM - preferentially lots of it.
Hard Drives - the faster the better.
As SSD's are Solid Sate Drives, they have no moving parts, therefore the
read/write is REALLY faster.
IF, and that's a big if, the so mentioned SPARC based servers have
outstanding hard drives and RAM memory, I fail to see where it should be
faster that any other type of similar hardware. Of course, if you need a
lot's of data transformation that is done by the server application,
then the SPARC may be faster. Otherwise...
If possible test the machine using data and with a workload that would
be used in your day-by-day applications. Then you'll be able to see for
yourself if this specific hardware fills your computational needs.
Obviously, I am not considering things like MTBF of the machine,
redundancy of PSU and other parts like controllers and hard disks,
replication and loadbalancing of the data servers to support 24x7 uptime
if necessary and things that make most managers have nightmares... but
that's another story.
Comparing OLTP 11g/12c performance just at x86 vs SPARC will need to at least do following -
1. Keep same memory
2. Keep same I/O response
3. Count total threads between x86 and SPARC
4. Keep in mind x86 has 0.5 multiplying factor
5. Identify SPARC multiplication factor
6. Thus for same processor license you can compare x86 and SPARC - ensuring apples to apples comparision
7. If OLTP transactions are very small - it is possible SPARC may come out ahead, but then you are for sure ignoring cost $$ per GHZ etc
8. In short I can't say in $$ terms it will make sense as any additional memory, disk (and SSD specifically) will cost much more for SPARC compared to typical x86
9. Oracle engineered systems may come out ahead in $$/performance matrix given budget constraint
Hope this helps
________________________________
This is a difficult question. Databases do a lot of locking of shared resources like
shared memory segments, buffer pools etc. For this kind of locking they use so called latches
which are implemented usually by very efficient machine instructions. If SPARC offers
some special very efficient instructions to implement such latches it could be that
it could be that Oracle DBs perform better on SPARC machines.
https://blogs.oracle.com/bestperf/simultaneous-oltp-in-memory-analytics:-sparc-t7-1-faster-than-x86-e5-v3
I am not surprised, here are some testing results Oracle published
A lot of this depends on your application. On average, x86 will hold it own against SPARC, other than in possibly unique environments. Biggest positive about x86 is multiple sources and the ability to grow horizontally at a much lower cost than SPARC. Let alone that SPARC will become obsolete in the not too distant future, in which most likely move will be to x86, so why not move now. Moreover, if there is a potential that you could move to the cloud, you will have better options with an x86 base than a SPARC base.
According to the experience in the company I work for, the "general purpose" and DSS/DWH perform better on Intel. I guess it's all about the application you run (and ours is quite heavy and complex), however in our case x86 deals better. We have about 512G of RAM, 128 CPUs (Intel(R) Xeon(R) CPU E7-8867 v3 @ 2.50GHz), running RHEL 6.7 and about 30Tb fiber IBM storage.
This is a Cloud implementation? I know Spark can be used on premise and without Hadoop but have not seen it done.
The decision here has been not to move ORACLE to the Cloud where we will use HORTON Works (Spark) on top of a Hadoop cluster. We are looking at Amazon. We are starting proof of concept testing with Amazon. The primary driver is a much reduced cost if we use Spark which should be faster as it is all in memory. The IO being the pain point for most processing.
I expect the best performance in CLOUD for ORACLE would be on the ORACLE Cloud so the specific Cloud environment would be an issue. It would also depend on if your application software is Spark compatible. Python and R seem to work very well older languages that require wrappers, not so much. The other issue being the performance advantages depend on the size of the data, the Hadoop is best leverage with large data sets. You would likely seen little or no gain with smaller data sets.
Testing shows that reading and loading data are very fast compared RDMS systems the problem is with Updates.
We are still testing options. Data Bricks or SAS Viya gives even better performance gains than Spark but are licensed products.
Our main driver has been cost.
hope this helps.
I agree with Bobin about SPARC is much better than x86.
I am running 42 dev databases on my x86 server and I don't find that working excellent although I have 256GB memory and 48 cores on the box.
However since SPARC is going to be obsolete soon, I would keep my systems on intel to be on supported hardware.
Also If I am not wrong, support cost for SPARC is higher too.
I will echo Bobin's observations re: Oracle stopping development. I think the key is to look at the price drops in high-end hardware, and scale out on a 1.5x ratio if migrating from SPARC to x86. Also, look at virtualization low-churn loads, and segment your database stores based on usage analytics and HA services.