Re: oracle v SS

From: Kellyn Pot'Vin-Gorman <dbakevlar_at_gmail.com>
Date: Fri, 8 Nov 2019 06:19:21 -0800
Message-ID: <CAN6wuX1oyftgB_kuLYK620A5f69ypD5WJjjfA8MMa8Vh8h4Xbg_at_mail.gmail.com>



Thank you, Malden for bringing up Azure Data Studio and the advancements in SQL Server with Linux, which is now GA with SQL Server 2019 this week.

I work for Microsoft- I work with the analytics and AI group, SPECIFICALLY in data platforms with Power BI. I KNOW its on-prem, too. The point was, just as what Malden also eluded to- You are focusing on just the on-prem solutions, forgetting that Microsoft has a larger investment in cloud and cloud services for database and analytics.

When I was asked how to create a deployment for my team for customers that would offer them the “Modern Data Warehouse”, I chose not to deploy on-prem with SQL Server, Analysis Server, SSIS packages and so on. I instead went to Azure SQL, (which is different) Azure SQL DW, Azure Analysis Services and Azure Data Factory pipelines/dataflows.

I cover a 1/3 of the US for Higher Education and seriously, only a handful of my customers are using on-prem for Power BI analytics at this point. Most of my Power BI gateway configurations are for their Oracle and other data sources I haven’t migrated up to Azure...yet. :)

Kellyn

On Fri, Nov 8, 2019 at 12:12 AM Noveljic Nenad <nenad.noveljic_at_vontobel.com> wrote:

> Hi Kellyn,
>
>
>
> I embedded my answers below.
>
>
>
> - Another suspicious default in SQL Server is "clustered index" (as
> opposed to heap table) as a data storage structure, which is similar to
> index organized table (IOT) in Oracle, just the IOTs performs much better
> because of the smarter implementation.
>
> > SQL Server architecture is different. Clustered indexes perform very
> efficiently vs. an IOT in Oracle, which has a very unique use case, but
> there is also less need for memory in the TempDB for sorting due to this
> design, (no PGA, either). Keep in mind, it's again not an apple to apple
> comparison when you only take the index structure into consideration.
>
>
>
> The access over a secondary index requires an additional clustered index
> lookup for getting a row. Consequently, if the clustered index depth is,
> say, four, this will require four additional logical reads per fetched row.
> To do justice to SQL Server, the clustered index lookup could be avoided by
> including all of the selected columns in the secondary index. However, this
> might become quite a challenging task in a DWH allowing ad-hoc queries. In
> contrast, Oracle tries to maintain ROWIDs in the secondary index, and
> therefore, doesn’t require those additional reads. I elaborated on that
> topic here:
> https://nenadnoveljic.com/blog/index-organized-table-vs-clustered-index/
> .
>
>
>
> - Oracle/Linux troubleshooting/performance tuning features are superior!
> SQL Server is slowly catching up, but it's still way beyond Oracle.
>
> > SQL Server is on Linux, which offers similar optimization tool
> availability.
>
>
>
> Unlike Oracle, SQL Server isn’t specifically compiled for Linux. There is
> a translation layer instead, see
> https://cloudblogs.microsoft.com/sqlserver/2016/12/16/sql-server-on-linux-how-introduction/
> . Consequently, the tools tracing user space calls can’t resolve addresses
> of SQL Server functions – which renders them unusable. For example, see a
> (cryptic) pstack output of a SQL Server process, which isn’t helpful at all:
>
>
>
> pstack 1095
>
> Thread 2 (Thread 0x7fe874b9f700 (LWP 2557)):
>
> #0 0x00007fe87ef5dcef in ppoll () from /lib64/libc.so.6
>
> #1 0x00005583a0cf7d41 in ?? ()
>
> #2 0x00007fe881b46ea5 in start_thread () from /lib64/libpthread.so.0
>
> #3 0x00007fe87ef688cd in clone () from /lib64/libc.so.6
>
> Thread 1 (Thread 0x7fe881f5e0c0 (LWP 1095)):
>
> #0 0x00007fe881b4e1d9 in waitpid () from /lib64/libpthread.so.0
>
> #1 0x00005583a0cf8373 in ?? ()
>
> #2 0x00005583a0d4c955 in ?? ()
>
> #3 0x00005583a0d4d61f in ?? ()
>
> #4 0x00005583a0d23eb1 in ?? ()
>
> #5 0x00005583a0ce27df in ?? ()
>
> #6 0x00007fe87ee8c545 in __libc_start_main () from /lib64/libc.so.6
>
> #7 0x00005583a0cdfbba in ?? ()
>
>
>
> In contrast, pstack output of an Oracle process provides a genuinely
> useful information:
>
>
>
> pstack 29069
>
> #0 0x00007f627002015a in semtimedop () from /lib64/libc.so.6
>
> #1 0x0000000012840365 in sskgpwwait ()
>
> #2 0x000000001283c4bb in skgpwwait ()
>
> #3 0x0000000012034d9a in ksliwat ()
>
> #4 0x000000001203414c in kslwaitctx ()
>
> #5 0x0000000012657e20 in ksarcv ()
>
> #6 0x0000000003a2837a in ksbabs ()
>
> #7 0x0000000003a46933 in ksbrdp ()
>
> #8 0x0000000003e2a8cd in opirip ()
>
> #9 0x00000000026d3265 in opidrv ()
>
> #10 0x0000000003185685 in sou2o ()
>
> #11 0x0000000000da9f1d in opimai_real ()
>
> #12 0x0000000003191821 in ssthrdmain ()
>
> #13 0x0000000000da9e40 in main ()
>
>
>
>
>
> - SQL Server comes with BI components (Reporting & Analysis Server, SSIS).
>
> > Most newer, advanced, more efficient products are not in SQL Server,
> but Azure DB and Azure in general. Power BI, Analysis Server,
> Hyperscale, Azure Data Factory). It may be less popular in the Oracle
> world, but I'm at one of the largest Microsoft conferences today and I can
> tell you, most of us have moved to the cloud and cloud products. SQL
> Server outside of Azure is when we have no other choice. There's so much
> more available in Azure.
>
>
>
> According to
> https://docs.microsoft.com/en-us/power-bi/report-server/install-report-server
> , Power BI is available on-premise as well.
>
>
>
>
>
> Best regards,
>
>
>
> Nenad
>
> ____________________________________________________
>
> Please consider the environment before printing this e-mail.
>
> Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
>
>
> Important Notice
> This message is intended only for the individual named. It may contain
> confidential or privileged information. If you are not the named addressee
> you should in particular not disseminate, distribute, modify or copy this
> e-mail. Please notify the sender immediately by e-mail, if you have
> received this message by mistake and delete it from your system.
> Without prejudice to any contractual agreements between you and us which
> shall prevail in any case, we take it as your authorization to correspond
> with you by e-mail if you send us messages by e-mail. However, we reserve
> the right not to execute orders and instructions transmitted by e-mail at
> any time and without further explanation.
> E-mail transmission may not be secure or error-free as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
> processing of incoming e-mails cannot be guaranteed. All liability of
> Vontobel Holding Ltd. and any of its affiliates (hereinafter collectively
> referred to as "Vontobel Group") for any damages resulting from e-mail use
> is excluded. You are advised that urgent and time sensitive messages should
> not be sent by e-mail and if verification is required please request a
> printed version. Please note that all e-mail communications to and from the
> Vontobel Group are subject to electronic storage and review by Vontobel
> Group. Unless stated to the contrary and without prejudice to any
> contractual agreements between you and Vontobel Group which shall prevail
> in any case, e-mail-communication is for informational purposes only and is
> not intended as an offer or solicitation for the purchase or sale of any
> financial instrument or as an official confirmation of any transaction.
> The legal basis for the processing of your personal data is the legitimate
> interest to develop a commercial relationship with you, as well as your
> consent to forward you commercial communications. You can exercise, at any
> time and under the terms established under current regulation, your rights.
> If you prefer not to receive any further communications, please contact
> your client relationship manager if you are a client of Vontobel Group or
> notify the sender. Please note for an exact reference to the affected group
> entity the corporate e-mail signature. For further information about data
> privacy at Vontobel Group please consult www.vontobel.com.
>

-- 



*Kellyn Pot'Vin-Gorman*
DBAKevlar Blog <http://dbakevlar.com>
President Denver SQL Server User Group <http://denversql.org/>
about.me/dbakevlar

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Nov 08 2019 - 15:19:21 CET

Original text of this message