Featured Database Articles
Arshad Ali takes a look at traditional analytics architecture, the challenges it faces, and how the newly introduced Real-time Operational Analytics feature overcomes those challenges.
In many cases Azure SQL Database offers an economically and functionally viable alternative to SQL Server deployments. However, there are also scenarios where we might discover that rather than serving as a replacement, it provides synergy, working side by side with your on-premises databases. One of technologies that illustrate this paradigm is Stretch Database, introduced in SQL Server 2016. We will describe its basic characteristics and review its implementation steps in this article.
With the introduction of temporal table support in SQL Server 2016 Microsoft also added some additional functionality that makes it easy for you to join the current and history records of a system-versioned table. Greg Larsen shows you some of the different ways to do analysis of your system-versioned records over time.
Careful testing and planning are crucial when deciding if an index is truly ‘unused’. Read on to see what could happen if testing isn’t thorough.
If you’re using invisible indexes, they may not be entirely ‘invisible’ to the optimizer. Read on to see why.
Without having an execution plan it’s difficult to know the degree of parallelism Oracle has selected. Read on to see how that can be reported.
Early data warehouse implementations began as collections of financial and customer data that accumulated over time. Modern warehouses have evolved into complex and elegant enterprise analytics platforms, hosting a broad collection of multiple data types, queried by advanced business intelligence software. As the warehouse environment becomes more valuable, capacity planning becomes critical. In this article we present several strategies for managing data warehouse capacity planning and performance tuning.
Lockwood Lyon presents simple SQL statements that the database administrator (DBA) can execute against the DB2 catalog to determine if your DB2 subsystem suffers from common maladies, and what the DBA can do to fix or mitigate potential problems.
Despite the sophistication of the latest DB2 software versions and the power of current IBM z/server technology, it is still possible for performance and data availability to deteriorate due to a variety of things, including increased dataset extents, loss of clustering, index page splits, and other factors. This article presents simple SQL statements that the database administrator (DBA) can execute against the DB2 catalog to determine if one or more application databases suffer from common maladies, and what the DBA can do to fix or mitigate potential problems.