Requirement: The user wants a report with a column chart. The X axis will have Subcategory Name and the value will be the sum of Internet Sales. Along with this chart, the user will have a slicer where they can select the Subcategory Names. The column chart should “update” showing one column for each selected subcategory, and another column named “Others” with the summed amount of the rest of the unselected categories.
Basically, they wanted a dynamic group called “Others” and the members within this group should change based on what is selected on the slicer.
This would be a good time to show a visual representation of what the requirement means.
Click through for that visualization, as well as the solution.
Stupid question… what’s the schema of a table with sys.sp_readerrorlog output? Well you might be surprised if you’re used to using nvarchar(max) or nvarchar(2048).
There’s a datetime (modern datetime2(3)) obviously. ProcessInfo is either “Server” or “spidxxxy” where xxx is an int (max of 11 characters including minus) and y is an optional single character suffix. But as for the text…
Let’s try to max it out!
Moral of the story: keep those error messages as short as possible while still being meaningful.
Compaction is a process by which HBase cleans itself. It comes in two flavors: minor compaction and major compaction.
Minor compaction is the process of combining the configurable number of smaller HFiles into one Large HFile. Minor compaction is very important because without it, reading particular rows requires many disk reads and can reduce overall performance.
Major compaction is a process of combining the StoreFiles of regions into a single StoreFile. It also deletes remove and expired versions. By default, major compaction runs every 24 hours and merges all StoreFiles into single StoreFile. After compaction, if the new larger StoreFile is greater than a certain size (defined by property), the region will split into new regions.
Read on for more information about compaction and data locality, which is a totally different topic.
Bingo. The application server could not connect to the SQL Browser service on UDP 1434. So maybe now you’re asking why, and that’s kinda the gist of this post. The SQL Browser provides a valuable service when an application tries to connect to a SQL Server named instance. The SQL Browser listens on UDP 1434 and provides information about all SQL Server instances that are installed on the server. One of those pieces of information is the TCP port number that SQL is listening on. Without that info, the application has no idea how to reach to your SQL Server, and will fail to connect. This was our exact issue.
Do read this, though my preference is to shut off the SQL Browser because it’s a mechanism attackers can use for gathering intel on where SQL Server instances live.
A fundamental component of SQL Server is the security layer. A principle player in security in SQL Server comes via principals. In a previous article, I outlined the different flavors of principals while focusing primarily on the users and logins. You can brush up on that article here. While I touched lightly, in that article, on the concept of roles, I will expound on the roles a bit more here – but primarily in the scope of the effects on user permissions due to membership in various default roles.
Let’s reset back to the driving issue in the introduction. Frequently, I see what I would call a gross misunderstanding of permissions by way of how people assign permissions and role membership within SQL Server. The assignment of role membership does not stop with database roles. Rather it is usually combined with a mis-configuration of the server role memberships as well. This misunderstanding can really be broken down into one of the following errors:
The belief that a login cannot access a database unless added specifically to the database.
The belief that a login must be added to every database role.
The belief that a login must be added to the sysadmin role to access resources in a database.
Worth reading. Spoilers: database roles are not like Voltron; they don’t get stronger when you put them all together.
Recently I was performing a security audit for a client. One of the many things I had to check was the enforcement of password policies for any SQL Server created accounts.
You know, that policy that says you must have some combination of 6 or more characters, upper and lower case, a number, and special characters, etc.
These policies are controlled by the server policy settings and were something easy to check. The actual passwords and that they were safe, not so much.
Click through for the script.
Once I update my statistics with fullscan, with in 10~20 seconds some of the statistics on the same table are getting update on secondary with a sample pecent of rows. Meaning my best statistics are being overwritten with good (full vs sample) statistics. On primary node once I run “Update statistics Tablename with fullscan” . I see following about statistics status.
After 10~20 seconds of updating statistics in primary node if I check the status of the same on my secondary nodes, I see fullscan statistics is replaced by sample statistics. Look at the rows_sampled and last_updated column, you will see the sample row number and last_updated column time is within few seconds of update in primary. RowsModified column still showing zero records.
It’s happening on an Availability Group secondary. Taiob has a workaround, so read on for that.
Now ignoring the fact that you already know what is wrong, this tells me that there is either something wrong with the
$sqlvariable or the syntax statement. Maybe even something else though!
This is not helpful and I’m going to have a bad time.
Shane also has an interesting side note around error colors.