This morning I decided to look into how to get my diagrams from draw.io to SharePoint. I found lots of information out there on how to insert visio diagrams as web drawings into SharePoint, but nothing on draw.io. So at this stage I think I’m just going to have to insert the diagrams as images. An alternative would be to ask Adam for access to visio, and re create my diagrams there in order to then insert them as web drawings. However, I would prefer the first method as it seems like less work is involved (me being lazy?), but I think the second option would be more effective in the long run. Here is a useful step by step set of instructions that will come in handy if I do in fact decide to follow through with the use of visio.
As everyone was busy catching up from the long weekend, I felt I couldn’t ask for anyone’s time. So I struggled to find anything else to continue on with. Because of this, I spent the rest of the day with Nadine, solving site status alerts and writing reports. Lots of reports!
The first thing I did this morning was send Kathryn a message asking if she had time to catch up. It turns out she isn’t on a board this morning, so she could catch up anytime! Which is great. This means I will now be able to make come more progress with my latest diagrams, and hopefully get them to a point where I am happy to show them to Adam. I do plan on also trying to catch up with Rosie later in the day/week to go over the Replication Alerts as she is the ‘Replication Guru’.
Kathryn actually went over all of the alerts with me, which I really appreciate! I do still want to go over these with the others also to get their views and ideas. So that will be my next step after updating the current diagrams to reflect Kathryn’s suggested changes.
I am still having some issues getting my head around the log shipping related resolution processes, as I’m not 100% sure I understand all of the issues which could cause these alerts to be triggered. So I will need to spend some time looking further in to log shipping. Below is some useful information I found from this source about log shipping FAQs:
- What editions of SQL Server is log shipping available in?
- 2012 – Enterprise, Business Intelligence, Standard, and Web
- 2008R2 – Datacenter, Enterprise, Standard, Web, and Workgroup
- 2008 – Enterprise, Standard, Web, and Workgroup
- 2005 – Enterprise, Standard, and Workgroup
- Does the secondary need to be licensed?
- I am not the licensing police, and I am not Microsoft – check with your licensing representative to clarify your exact situation. Generally, you can have one warm standby server. However, the second someone starts using it for reporting, testing, or anything else, you need to license it like any other server.
- Log shipping is compatible with backup compression. What edition of SQL Server do I need to take advantage of compression?
- 2012 – Enterprise, Business Intelligence, or Standard
- 2008R2 – Datacenter, Enterprise, or Standard
- 2008 – Enterprise
- 2005 – Not available
- When log shipping is set up, Agent jobs are created to alert me if a backup, copy, or restore fails. How do I get notified?
- You need to go into the Agent job, pull up Notifications, and choose your method – email an operator, or write to the event log, for example.
- Are my logins shipped from the primary to the secondary?
- No, they are not. You’ll need to set up a separate method to sync the logins.
- Does this replace, or can it be combined with, our existing daily full and log backups?
- TL; DR – no.
- You’ll still want to take regular full and/or differential backups. Log shipping only takes one full backup – at the beginning – and that’s only if you specify that it does so. It can also be initialized from an existing full backup.
- Taking two log backups in separate jobs will break the log chain, however. If you implement log shipping, it will replace your current transaction log backup job.
- What’s the difference between the secondary being in “Restoring” vs. “Standby”?
- Restoring means the database is not accessible. Standby means it is read-only. You make this decision when you set up the log shipping.
- If the database is in Standby mode, users can query it – except when a log backup is being restored. You need to decide if a restore job will disconnect users, or if the restore is delayed until after the users are disconnected.
You might also remember me mentioning in a previous post that I couldn’t find any information about Severity 25 errors. Well, while trying to refine the diagram after speaking with Kathryn, I found some information online. Here’s what I found:
Older versions of SQL Server had Severity Level 25 but it is an unexpected system error and doesn’t list in SQL Server 2012’s sysmessages catalog view (which explains why it didn’t show up when i queried my lab Instances).
However most sources still provide this information (as found previously):
This morning was consumed by more and more research around Log Shipping. Although I do understand how log shipping itself works, and the different components involved, I still want to gain a better understanding of what can stop the jobs from working, in other words what causes the SQL Server alerts to be triggered.
After hours of trawling through the internet, I decided to employ the help of Slade. Slade was an enormous help in clarifying what causes the jobs to fail and what you would then need to do to resolve this. So thank you Slade! I do find it so much more helpful to discuss these sorts of issues with members of the team rather than solely relying on google for the following two reasons. Firstly, there is so much information to sift through online that the task of picking out the useful bits is both time consuming and daunting. Secondly, it seems hard to find answers specific to my needs, whereas asking the question face to face provides a much more useful and relevant answer, usually in terms that are easier to understand.
Later in the afternoon I had the chance to go over a few more alerts with Rosie, so this helped refine the diagrams again and get them closer to where they eventually need to be.
At the end of the week I have now spent 185.5 hours at SQL Services