Hi Andreas,

No we wouldn't be able to use a listener as you say - we would need to refer to each node separately by IP address and handle the failover...

• This reply was modified 2 years ago by  mg_dba.

Thanks all, Jeff's reply had me thinking about Query Store as we're on SQL 2019. Potentially both worth looking into though, cheers!

You are probably right Jeff, the actual use case is to log specific query executions to a table...but now you've got me thinking of other potential ways...🤔

It's partly for performance...

• This reply was modified 2 years, 8 months ago by  mg_dba.

Brilliant, thank you both - very useful links!

Thanks ChrisM, that's an interesting idea. I've just tried it using Phil's suggestion and it updated 20,000,000 rows on a cold cache in almost exactly 4 minutes (and only running...

Ah of course! That would make much more sense...why didn't I think of that.... :ermm: Haha

I'll give that a try - thanks very much!

ChrisM@Work (7/21/2016)

---

matt.gyton (7/20/2016)

---

Think I may have a solution!

I experimented with the plans by comparing the two XML versions on a diff checker and they came up almost identical with...

So it turns out my earlier optimism was slightly misplaced....the code change did not provide the fix 🙁

However, I noticed that it temporarily improved performance until the SP ran with...

Thanks Jeff, I wasn't aware of that...just read the article - looks interesting! I don't think we suffer too heavily from TempDB contention at present, but it's certainly worth looking...

Think I may have a solution!

I experimented with the plans by comparing the two XML versions on a diff checker and they came up almost identical with the exception...

Hi All,

Many thanks for all your responses. I have restored a fresh copy of the database to try and ensure there are no differences and all these things appear to...

Table definition:

[TK_ROWID] [int] NOT NULL,

[SEQ_COMPANY] [varchar](6) NOT NULL,

[SEQ_LEDGER] [varchar](6) NOT NULL,

[SEQ_TYPE] [varchar](6) NOT NULL,

[SEQ_DESCRIPTION] [varchar](40) NULL,

[SEQ_SHORT_DESC] [varchar](20) NULL,

[SEQ_NEXT_BATCH] [int] NULL,

[SEQ_NEXT_TRANS] [int] NULL,

[SEQ_ACTIVE] [varchar](1) NULL,

CONSTRAINT [PRI_SEQUENCE] PRIMARY KEY CLUSTERED

(

[TK_ROWID]...

Sorry just one more thing that's puzzling me about this....

The processes become deadlocked when both are attempting to run the following query:

UPDATE GL_SEQUENCE SET @NEXT_TRANS_INT_REF = SEQ_NEXT_TRANS = SEQ_NEXT_TRANS +...

Aaaah I see - many thanks....still getting my head round these a bit...!

Jason-299789 (9/18/2014)

---

What actually happened to the cluster did it throw a disk?

as its possible a file that SSAS needs to start up may be corrupt or missing.

This might...