« first day (3179 days earlier)      last day (33 days later) » 

6:28 AM
7:01 AM
7:17 AM
7:42 AM
Can someone help me understand this scenario? I have log shipping set up between servers A and B. I take full backups on A manually and transfer and restore them on B manually. Backup logs are taken and restored automatically according to a schedule. The schedule has a window for me take and restore a full backup.
Now, a full backup was taken in time but I failed to restore it in time before the window time ran out and log backups started shipping again. More specifically, I hadn't even started restoring the full backup before the first log backup from the new series was restored. What I'm observing is that the new log backups still appear to be restoring at the destination successfully, even though they are based on a full backup that I haven't restored yet at the destination.
Is that to be expected? Or am I misinterpreting something?
Would that perhaps make sense as a question on the main, or does it sound too localised?
@AndriyM Sounds fine to me. FULL's don't truncate the log
So all transactions are still in the log ready to be backed up, following the full backup
@AndriyM I've got an answer somewhere where I tested that.
@George.Palacios That appears to be what I was missing, thanks (FULL's not truncating the log).
7:47 AM
My understanding of the use of the FULL in that scenario is to physically cut down the number of log backups that need to be reapplied.
Given a particular point in time you want to reach. But our log shipping boxes we never bothered restoring a FULL unless the log shipping db died for whatever reason
@George.Palacios I didn't know that you didn't need to restore the FULLs to continue to apply the log backups.
@AndriyM I didn't even know you could apply a FULL on top of a restoring database
Unless you delete the DB each time?
A: How to tell if a backup log chain is broken?

hot2useReference Reading / Similar Q&As You might want to check out my answer that I posted in response to the question: Will VSS backups break logchain? (dba.stackexchange.com) The explanation in my answer also links to the question How can I backup an SQL Server database using Windows Server Backup...

A full does not break the TLOG backup chain.
You can lose a full backup and still restore the database using existing TLOG backups.
You only lose the ability to restore with TLOG backups if you lose a TLOG backup file.
If you have a FULL and any amount of TLOG files, then the restore will work up until any missing TLOG file (or till the end).
@EvanCarroll flagged
@EvanCarroll Looool. I can guarantee that the accepted answer isn't the origin of the phrase
7:58 AM
> as long as you have an unbroken chain of FULL and TLOG backups you can access, you can still restore your database to any point in time, even if you have another FULL backup in-between.
^^^ I already understood that from the discussion above but that sentence summarises it perfectly. Thanks @hot2use!
But just to clarify, if I have several full backups and an uninterrupted series of TLOG backups in-between them and following the last full, I can restore the database using any of the full backups as a starting point. I will just need to apply a different number of TLOG backups afterwards, depending on which full I choose, correct?
@AndriyM Correct
Also, replace FULL with FULL + DIFF and the principal still applies
I haven't done DIFFs so far. I understand the concept, just never tried them. Our nightly backup job is too primitive to handle them, I guess.
On which cases do you prefer log shipping instead of AO?
8:25 AM
@McNets Not sure if you were asking me or anyone in general, but just to make it clear, it's the first time in my life I'm working with log shipping. Haven't developed any preferences yet :)
AO is a pig in terms of useless error messages
And I haven't used AO at all yet
I'm planning to add a read-only DB for reporting purposes and another point of DR. I'm learning (on my own), how to set up a basic AO but maybe log shipping fits better in this case.
@McNets If you're using synchronous commit, be wary that read operations on the secondary can cause writes and page splits on the primary
That hit us hard recently with massive row version cleanups that send disk latency through the roof in hotspots
@George.Palacios ok thanks
@George.Palacios can I configure the replica as asynchronous commit?
I mean just to avoid this issues
8:49 AM
I'd play around with it though
We just had some stupid users running massive queries
9:00 AM
@JackDouglas really though?
fwiw i think the other answers are "more correct", but there's a non-zero amount of correct linguistic context in that answer
flagging it b/c it's distasteful is rather ironically on flavour for the quote linked in in the OP
9:50 AM
@PeterVandivier offensive to British — he's saying we are irrational, and calls "Life of Brian" perverse which is sacrilege ;)
still though, if you did actually flag it, i hope on principle it's declined
i noticed it got 3 new downvotes though so i'm not optimistic
@McNets Also, temporary statistics creation can hurt performance. Either when using log shipping or a secondary replica.
@George.Palacios Cool stuff, have you found a blogpost or Q/A about these issues? I would like to read up on that
@JackDouglas bad words for Life of Brian is major offence!
Cuckoo's Nest and Life of Brian were the first 2 films I've seen when I moved for university.
@George.Palacios Nvm found here =)
10:16 AM
@RandiVertongen ok thanks
@JackDouglas possible release dates for Postgres 12. RC1: Sep-26 and GA a week later.
@ypercubeᵀᴹ cool. SQL Server 2019 and Oracle 19 XE will probably both arrive on the same day as pg12 :)
10:51 AM
@RandiVertongen Yeah - Snapshot isolation - it's a good architecture but a readable secondary isn't quite as "free" as I first thought
11:02 AM
For those wanting some context, when Life of Brian was released there was a great storm in a teacup with various folks calling it blasphemous. There was a famous televised debate staged between the Pythons and various religious bigwigs.
1 hour later…
12:09 PM
@ConcernedOfTunbridgeWells enjoyed that, thanks for the links!
1:03 PM
Q: Сardinality estimation of partially covering range predicates

Павел Ковалёвat the moment I'm trying to figure out how Sql Server evaluates the cardinality of range predicates that partially cover the histogram step. On the Internet, at cardinality-estimation-for-and-for-intra-step-statistics-value I came across a similar question and Paul White gave a rather interestin...

3 hours later…
4:49 PM
I knew they would try that.
We'll see.. good move by them anyway to hold their ground.
I question whether or not graph query languages should occur under the regular SQL umbrella or not.
It seems like not placing them as a subset of the SQL spec is a mistake for marketing reasons.
By any extent, it's safe to say that Cypher will become/is a standard of some sort. And other databases like PostgreSQL are actively looking at building graph backends for their databases.
JSON/sql for example is a totally fine spec, for querying JSON and it happened under the SQL umbrella.
It doesn't seen evident to me why a graph database would need to happen independent of SQL

« first day (3179 days earlier)      last day (33 days later) »