A Fine Slice Of SQL Server
Your transaction log is full. Both Microsoft, and about 100 articles and blogs have covered this topic, but let’s take a quick look anyway. Because, you know, it comes up all the time.
Summary:
This error message points to a lack of log backups.
Make sure using sys.databases.
Start backing up the log.
You can shrink the log if necessary.
A note on SIMPLE mode, and why it’s often a terrible idea.
This is a good summary of the problem and various solutions.
Comments closedMichael J. Swart tests whether ORDER BY NEWID() produces a biased result:
One of his articles, Visualizing Algorithms has some thoughts on shuffling at https://bost.ocks.org/mike/algorithms/#shuffling.
He says that sorting using a random comparator is a rotten way to shuffle things. Not only is it inefficient, but the resulting shuffle is really really biased. He goes on to visualize that bias (again, I really encourage you to go see his stuff).
Ordering by random reminded me of the common technique in SQL Server of
ORDER BY newid(). So I wondered whether an obvious bias was present there. So I shuffled 100 items thousands of times and recreated the visualization of bias in a heat map (just like Mike did).
I’ve used this pattern to good effect, but definitely pay attention to Michael’s warning at the end.
Comments closedErin Stellato explains why enabling Query Store requires the plan cache be flushed:
I’ve had two comments recently on my blog about Query Store causing the plan cache to be flushed. There was a known issue related to the plan cache flushing after Query Store was enabled, but this was fixed in CU2 for SQL Server 2016 SP1. So I did some testing and here is what I think is causing the confusion:
When you enable Query Store, which is done with an ALTER DATABASE SET statement, the plan cache for the database is flushed.
Now, before anyone writes up a UserVoice item, understand that there are several ALTER DATABASE SET commands that cause the plan cache for a database to be flushed. For example, taking a database OFFLINE causes the database plan cache to be flushed. That one seems intuitive, right? So why is the plan cache cleared when you enable Query Store, or change one of the settings? To ensure that new Query Store data is not lost. This relates to the internals of how Query Store works, which aren’t essential to dig into, the point is that this behavior is known by Microsoft and expected.
There is what I’d consider a documentation bug around describing what happens when you enable Query Store, but the fact that the plan cache gets cleared makes sense.
Comments closedJohn Mount announces wrapr 1.5.0:
wrapr includes a lot of tools for writing better
Rcode:
let()(let block)
%.>%(dot arrow pipe)
build_frame()/draw_frame()(data.framebuilders and formatters )
qc()(quoting concatenate)
:=(named map builder)
%?%(coalesce) NEW!
%.|%(reduce/expand args) NEW!
uniques()(safeunique()replacement) NEW!
DebugFnW()(function debug wrappers)
λ()(anonymous function builder)
John also includes an example using the coalesce operator %?%.
To get GPU support, you need both hardware with GPUs in a datacenter, as well as the right software – namely, a virtual machine image that includes GPU drivers so you can use the GPU.
The biggest tip is to use the Deep Learning Virtual Machine! The provisioning experience has been optimized to filter to the options that support GPU (the NC series – see below), which make it easier to set it up correctly.
Read on for the rest of the advice.
Comments closedGour Saha, et al, demonstrate running Apache Hive LLAP as a YARN service:
Making LLAP as a first-class YARN service also enables us to use some of the other powerful features in YARN that were added in Apache Hadoop 3.0 / 3.1, some of them are noted below.
Advanced container placement scheduling such as affinity and anti-affinity. What Slider used to handle in a custom way is now a core first-class feature (YARN-6592).
Rich APIs for users to fetch/query application details using Timeline Service V2 (YARN-2928 and YARN-5355).
New and improved Services UI in YARN UI2 improving debuggability and log access.
Continuous rolling log aggregation of long running containers (YARN-2443).
Auto-restart of containers by NodeManagers (YARN-4725).
Windowing and threshold based container health monitor (YARN-8122).
In the future, we can also leverage YARN level rolling upgrades for containers and the service as a whole (YARN-7512 and YARN-4726).
Looks like it’s been a fruitful transition.
Comments closedIf you frequently connect to many different SQL Server as I do, you are probably used to the Server Manager loading slowly when you log in with Remote Desktop.
The Server Manager has a bad reputation for taking up lots of CPU over time and possibly even bogging down a SQL Server when left open for days on end.
To prevent this from automatically loading you can do the following to quickly disable it for your user session, and your future user sessions.
Read on for the steps.
Comments closedJanusz Rokicki explores what is available in Azure SQL Data Warehouse when it comes to auditing:
Auditing is disabled by default and the UI experience depends on the region to which the logical server is deployed. For instance, in UK South, the portal offers no options to manage auditing:
In North Europe, the portal allows Table Auditing (table-storage based) to be enabled on the SQL Data Warehouse scope, but it isn’t possible to enable Blob Auditing:
On top of that, Blob Auditing behaves differently when enabled on a logical server level in different regions. In locations that support Table Auditing, turning on Blob Auditing automatically enables it in all databases, including SQL Data Warehouses—and that’s expected. In other regions, Blob Auditing is not automatically enabled and has to be turned on programmatically by calling ARM REST API.
I imagine the plan is to support this across the board but it’s rolling out region by region.
Comments closedKevin Ngo announces a new feature in Azure SQL Data Warehouse:
Previously, SQL DW supported only automated snapshots guaranteeing an eight-hour recovery point objective (RPO). While this snapshot policy provided high levels of protection, customers asked for more control over restore points to enable more efficient data warehouse management capabilities leading to quicker times of recovery in the event of any workload interruptions or user errors.
Now, with user-defined restore points, in addition to the automated snapshots, you can initiate snapshots before and after significant operations on your data warehouse. With more granular restore points, you ensure that each restore point is logically consistent and limit the impact and reduce recovery time of restoring the data warehouse should this be needed. User-defined restore points can also be labeled so they are easy to identify afterwards.
Creating a user-defined restore point is a one-liner in Powershell, and it’s something you could do after each warehouse load, for example.
Comments closedSo far so good. Now let’s throw in a twist. Let’s call it through a linked server.
INSERT INTO [(local)\sql2014cs].Test.dbo.IdentTest VALUES ('Col1','Col2');Msg 213, Level 16, State 1, Line 4
Column name or number of supplied values does not match table definition.Well that’s a bit odd, right? I mean I used that exact command in the previous test. Turns out that when you do an insert across a linked server that identity column is not ignored. Which means we just need to include the identity value right? Nope.
INSERT INTO [(local)\sql2014cs].Test.dbo.IdentTest VALUES (1,'Col1','Col2');Msg 7344, Level 16, State 1, Line 4
The OLE DB provider “SQLNCLI11” for linked server “(local)\sql2014cs” could not INSERT INTO table “[(local)\sql2014cs].[Test].[dbo].[IdentTest]” because of column “Id”. The user did not have permission to write to the column.
Click through to see how to do this.
Comments closed