Another version, trying to do the least prep work possible (although for determining day or month first, the entire staging table may need to be scanned):

--Assumes that...

ALTER TABLE dbo.table_name ADD MinuteToHour AS CONVERT(char(5), DATEADD(MINUTE, CONVERT(int,[sun_total]), '19000101'), 108);

We're seeing only a partial plan with none of the actual stats and no sql query text.  I can't offer any real guidance with such limited info.

I don't think going back just 1 row will be accurate, at least as I understand the requirements (which, of course, could be incorrect).  For example, assume times of:

12:24; 12:25;...

Something along these lines should let you generate the code:

DECLARE @sql nvarchar(max)

;WITH
cte_tally10 AS (
    SELECT * FROM (VALUES(0),(0),(0),(0),(0),(0),(0),(0),(0),(0)) AS numbers(number)
),
cte_tally1000 AS (
  ...

Based on my reading of Netezza syntax online:

IF DATE_PART('DOW',CURRENT_DATE) IN ('3','6') THEN

statement

[statement] ...

END IF;

The two UPDATEs are already executed in separate transactions.  Since you don't have an explicit BEGIN TRANSACTION, every statement will be treated as a separate transaction by default.

Since the subquery...

You can add SET ARITHABORT ON to the trigger, but it may not help, because the error may be raised when the trigger is compiled the first time.

I don't understand...

You can use SET ARITHABORT and other SET statements within the trigger itself.  Those settings will be discarded when the trigger ends, so you can't do any harm to outside...

One should always try to avoid a function on a table column being used for lookup.  Therefore, for the last JOIN, do this instead:

  LEFT JOIN...

You don't really need to join, an EXISTS check will do fine.  The optimizer may rewrite it that way anyway, but it doesn't hurt to code it that way yourself:

You could also add a new filegroup and move the large tables into the new filegroup.  Then shrink the original file.  The big disadvantage, of course, is that you now...

Try:

EXEC sys.sp_depends 'BotCBO.vwClovekNameStrings_PrZk'

I've never been able to find a way to do this.  I ended up using CONTEXT_INFO() [*] or sp_set_session_context to pass the database_id to the called proc. [*] With provisions...

The easiest way to verify it is to look at the query plan.  You should be able to see that SQL is not actually pulling all the columns from that...