In the spirit of things no one asked for, I thought I would share a little something of how I’ve been dealing with the recent discontinuation of $v for LoC subject headings. To be fair, they were junking up the “Concepts” filter in Vega, so I can’t say I’ll miss them that much, but figuring out how to deal with an overnight change that impacts nearly all of our Bibs was a little daunting. I knew I could remove a subfield from a specific tag with Bibliographic Bulk Changes, but touching so many records made me a little nervous… so I did what any sensible person would do and wrote a query to back up all potentially affected bibliographic tags 
It goes a little something like this:
SELECT [BibliographicRecordID]
,(SELECT [BrowseTitle] FROM [BibliographicRecords] WHERE [BibliographicRecordID] = t.[BibliographicRecordID]) AS BrowseTitle
--,t.[BibliographicTagID]
--,[Sequence]
,[TagNumber]
,[IndicatorOne]
,[IndicatorTwo]
--,[EffectiveTagNumber]
,[CompleteTagData]
--Specify tag number(s) (and indicators) in subquery to keep the scope reasonable
FROM (SELECT [BibliographicRecordID],[BibliographicTagID],[TagNumber],[IndicatorOne],[IndicatorTwo]
FROM [Polaris].[Polaris].[BibliographicTags] WHERE [TagNumber] = 650
/*AND [IndicatorOne] = 9 AND [IndicatorTwo] = 0*/) AS t
--Subfield aggregation subquery to reconstruct data as a 'normal' MARC tag
--Inner Join is more effective than filtering SubCheck after Join for large number of results
INNER JOIN (SELECT [BibliographicTagID]
,STRING_AGG(CONCAT('‡',[Subfield],[Data]),'') WITHIN GROUP(ORDER BY [SubfieldSequence] ASC) AS [CompleteTagData]
,MAX(CASE WHEN [Subfield] = 'v' THEN 1 ELSE 0 END) AS SubCheck --Boolean check for specific subfield
FROM (SELECT [BibliographicTagID]
--,[BibliographicSubfieldID]
,[SubfieldSequence]
,[Subfield]
,[Data]
--,[NumberOfNonFilingCharacters]
FROM [Polaris].[Polaris].[BibliographicSubfields]
) AS s
GROUP BY [BibliographicTagID]
) AS s
ON s.[BibliographicTagID] = t.[BibliographicTagID]
AND [SubCheck] = 1
AND (SELECT [RecordStatusID] FROM [BibliographicRecords] WHERE [BibliographicRecordID] = t.[BibliographicRecordID]) = 1
So that you don’t have to use your imagination, this is what the output looks like:
Now, it’s a bit of a slow query (I’m sure @wesochuck will spot something that would improve optimization immediately 
), but it is running on all of the MARC data in the system, so it was never going to be “fast”. Ultimately, it gave me the list I wanted, including the BibliographicRecordID, tag number, indicators, and formatted MARC data, so that if for some reason LoC or our local catalogers decide they’d prefer to restore the $v data, it wouldn’t be lost forever. It would still be a royal pain to try to unwind a change like this, but it gave me peace of mind I needed to execute that absurd Bulk Bibliographic Changes job… which, all things considered, went off without a hitch:
There were a few records that I had to go back and edit later because they were locked by staff at the time the job got around to them (it did run for nearly 19 hours…), but that was about it. No one reported any noticeable slow down or anything, so I’ll count that as a win. The only real issue is that now almost all of our punctuation is messed up (since $v was typically the last subfield in the tag)… if anyone has ideas on how to fix that without re-importing/overlaying all of our Bibs, please let me know!