Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Запуск процедуры средствами Jobs  [new]
master
Member

Откуда: Тольятти
Сообщений: 2
Люди! Подскажите кто знает.
Есть в MS SQL 7.0 отлаженная процедура. Выполняется без проблем и с QA и с Visual Studio.
Но упорно не хочет исполняться через Jobsы. Даже если запускаю принудительно, а не по расписанию. Пишет String or binary data would be truncated. [SQLSTATE 22001] (Error 8152) The statement has been terminated. [SQLSTATE 01000] (Error 3621). The step failed.

Может кто сталкивался с таким?
Заранее благодарен.
30 май 01, 06:29    [7528]     Ответить | Цитировать Сообщить модератору
 RE:Запуск процедуры средствами Jobs  [new]
Глеб Уфимцев
Guest
Вообще-то этого надо избегать. Что-то обрезается у тебя в стрингах. Чтобы подавить это предупреждение, можно выставить
SET ANSI_WARNING OFF
перед запуском процедуры в том же коннекте, или внутри процедуры в её начале.
Более правильным будет найти то место, где строка длиной в 200 символов вставляется в поле varchar(199) и поправить. Очень часто такая ошибка встречается при операциях конкантенации строк и вставки их во вр. табличку, так как там трудно заранее выяснить длину строки.

По умолчанию для соединений через DBLib стоит SET ANSI_WARNING OFF, а для соединений через ODBC и ADO/OLEDB стоит SET ANSI_WARNING ON. Кроме этого, практически каждое клиентское средство имеет свои настройки, так или иначе меняющие эту установку. Этим и объясняется разница в поведении. Единственно правильным вариантом считается SET ANSI_WARNING ON и избегание ситуации неявного обрезания данных. SET ANSI_WARNING OFF - о лукавого, и крайне не рекомендуется в качестве метода правки багов.
30 май 01, 09:49    [7529]     Ответить | Цитировать Сообщить модератору
 RE:Запуск процедуры средствами Jobs  [new]
master
Member

Откуда: Тольятти
Сообщений: 2
Спасибо Глеб за совет.

Но проблему я пока так и не решил. Со строковыми данными я в процедуре вообще ничего не делаю.
Использую временную таблицу и курсоры. Может ли это как то влиять?
А SET ANSI_WARNING OFF так и не смог установить ни в процедуре, ни в самих джобсах. пишет is not a recognized option.

Ты пишешь, что исполнение процедур по расписанию нужно избегать. А почему? И какая есть альтернатива?
1 июн 01, 05:26    [7530]     Ответить | Цитировать Сообщить модератору
 RE:Запуск процедуры средствами Jobs  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
2 master
Проверьте поля временной таблицы и данные, которые туда закачиваете, может не совпадать размерность.
1 июн 01, 05:37    [7531]     Ответить | Цитировать Сообщить модератору
 RE:Запуск процедуры средствами Jobs  [new]
Глеб Уфимцев
Guest
> Использую временную таблицу и курсоры. Может ли это как то влиять?

Да. Там, скорее всего идет вставка данных в поле меньшего размера, чем размер исходных данных.

> А SET ANSI_WARNING OFF так и не смог установить ни в процедуре, ни в самих джобсах. пишет is not a recognized option.

Я очепятался. не ANSI_WARNING, а ANSI_WARNINGS. Советы не отменяют смотрение хелпа на предмет подробностей, а лишь являются наводками, куда рыть дальше.

> Ты пишешь, что исполнение процедур по расписанию нужно избегать. А почему? И какая есть альтернатива?

Имелось в виду, что следует избегать ситуации, при которых возможно подобное сообщение. На практике это означает, что если ты сливаешь данные из поля таблицы с типом varchar(100) во временную таблицу, то поле временной таблицы, получающей данные не должны быть короче varchar(100). То же справедливо и для переменных.
1 июн 01, 07:33    [7532]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Запуск процедуры средствами Jobs  [new]
Сергей Товстыко
Guest
В продолжение темы:

У меня не работает вот такая конструкция:
ALTER PROCEDURE RunTest (@id int,@bd varchar(1),@pp varchar(50)) as
declare @err int,@name varchar(50)
declare @nbd varchar(50),@cmd varchar(200)

-- опеределятся имя таблицы результата
select @name=com from verlist where id=@id and basename=@bd
-- проверка на существоввание и удаление старой
if exists (select * from rep.dbo.sysobjects where xtype='U' and name=@pp)
begin
exec ('drop table rep.dbo.'+@pp)
update verlist set error=0, lastrun=getdate() where basename=@bd and id=@id
end

-- выбор тестируемой базы
select distinct @nbd=bd from test.dbo.setfirms where cod=@bd
-- формирование строки запуска и выполнение
select @cmd='use '+@nbd+' if exists (select * from sysobjects where xtype=''p'' and name='''+@name+''') execute '+@name+' else execute test..'+@name
exec (@cmd)

-- оценка результов проверки и занесение в общуюю таблицу результатов
set @err=@@rowcount
update verlist set error=@err, lastrun=getdate() where basename=@bd and id=@id
select @err as error


Причем выдает тоже сообщение.
Структура таблицы вот

UPDATE [test].[dbo].[VerList]
SET [basename]=<basename,varchar(1),>, [id]=<id,int,>, [name]=<name,varchar(50),>, [com]=<com,varchar(70),>, [lastrun]=<lastrun,datetime,>, [error]=<error,int,>, [comm]=<comm,text,>, [Autonum]=<Autonum,decimal(18,0),>

Как видно из данных обновляются только два поля, но именно на этих updat-ах и глохнет. Должно выполняться на MS-SQL 2000 SP3, под sa.
5 июн 03, 10:56    [222500]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
snake
Member

Откуда: Russia, Penza
Сообщений: 2290
сдается мне не UPDATE здесь виноваты.
5 июн 03, 11:35    [222564]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
Сергей Товстыко
Guest
все проверено раз 10 :(

вот именно комментирование этих 2 строк и позволяют ей выполняться. Но тогда не готовится таблица результатов.
5 июн 03, 11:39    [222571]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
snake
Member

Откуда: Russia, Penza
Сообщений: 2290
Вообще трудно тут гадать чего у вас там не так.
По сему, если желаете разобраться, вот Вам мой скрипт -
доведите его до состояния этой ошибки тогда продолжим.
create table #t (bd varchar(1), col datetime)

go
declare @bd varchar(5)
set @bd = 'aвццв'
insert #t (bd ,col) select 'a', getdate()
select * from #t
update #t set col = getdate() where bd = @bd
select * from #t
drop table #t
5 июн 03, 11:50    [222596]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
Сергей Товстыко
Guest
Спасибо за помощь.

"Дело было не в бобине..." (С) Электрик
Там на эту таблицу один "пионэр" повесил триггер который и мешал выполнению :(
5 июн 03, 12:31    [222670]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
snake
Member

Откуда: Russia, Penza
Сообщений: 2290
Сергей Товстыко,
последний вопрос - земляк?
5 июн 03, 12:42    [222691]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Запуск процедуры средствами Jobs  [new]
Alex5555555555
Member

Откуда:
Сообщений: 114
Возникла такая же ошибка

Arithmetic overflow error converting expression to data type int. [SQLSTATE 22003] (Error 8115) The statement has been terminated. [SQLSTATE 01000] (Error 3621). The step failed.

Сегодня до 6 утра отрабатывал отлично и вдруг какие то грабли

джоб UCP - sysutility_mi_collect_performance, под sa выполняет EXEC[msdb].dbo].sp_sysutility_mi_collect_dac_execution_statistics_internal]

что это может быть?







блог
17 авг 12, 12:16    [13025669]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
Glory
Member

Откуда:
Сообщений: 104751
Alex5555555555
Возникла такая же ошибка

Ошибка - другая. Еще древнее тему не нашли ?

Alex5555555555
что это может быть?

Это - ваша процедура, которая что-то конвертирует в int

Сообщение было отредактировано: 17 авг 12, 12:31
17 авг 12, 12:31    [13025809]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
Alex5555555555
Member

Откуда:
Сообщений: 114
Glory,

это я понял, про int, а где проблему рыть?
17 авг 12, 12:34    [13025841]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
Glory
Member

Откуда:
Сообщений: 104751
Alex5555555555
это я понял, про int, а где проблему рыть?

В процедуре sysutility_mi_collect_performance, где же еще
17 авг 12, 12:36    [13025853]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
Alex5555555555
Member

Откуда:
Сообщений: 114
Glory,

подскажите пожалуйста варианты решения проблемы
17 авг 12, 12:42    [13025943]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
Glory
Member

Откуда:
Сообщений: 104751
Alex5555555555
подскажите пожалуйста варианты решения проблемы

Открыть текст процедуры
Найти команду, вызвавщую ошибку
Исправить команду
17 авг 12, 12:43    [13025950]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
Alex5555555555
Member

Откуда:
Сообщений: 114
Glory,
ошибка в квери

sg 8115, Level 16, State 2, Procedure sp_sysutility_mi_collect_dac_execution_statistics_internal, Line 40
Arithmetic overflow error converting expression to data type int.

лайн 40....пустая, подскажите может быть

автор
USE [msdb]
GO
/****** Object: StoredProcedure [dbo].[sp_sysutility_mi_collect_dac_execution_statistics_internal] Script Date: 08/17/2012 12:08:13 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[sp_sysutility_mi_collect_dac_execution_statistics_internal]
AS
BEGIN
DECLARE @current_collection_time datetimeoffset = SYSDATETIMEOFFSET();
DECLARE @previous_collection_time datetimeoffset;

-- At this point the session stats table should contain only rows from the prior collection time (or no
-- rows, in which case @previous_collection_time will be set to NULL). Retrieve the prior collection time.
SELECT TOP 1 @previous_collection_time = collection_time
FROM dbo.sysutility_mi_session_statistics_internal
ORDER BY collection_time DESC;

-- Get a list of the DACs deployed on this instance. In the sysdac_instances view, some of these values
-- are unindexed computed columns. Store them in a temp table so that we get indexed retrieval by dbid
-- or db/instance name and stats on the columns we'll use as join columns.
CREATE TABLE #dacs (
dac_instance_name sysname PRIMARY KEY,
database_name sysname UNIQUE,
database_id int UNIQUE,
date_created datetime,
[description] nvarchar(4000));

INSERT INTO #dacs
SELECT DISTINCT
instance_name,
database_name,
DB_ID(database_name),
date_created,
[description]
FROM dbo.sysdac_instances
-- Filter out "orphaned" DACs that have had their database deleted or renamed
WHERE DB_ID(database_name) IS NOT NULL;

-- Step 1: Capture execution stats for all current sessions in DAC databases. Now this table should
-- hold two snapshots: one that we just inserted (referred to as the "current" data from here on), and
-- the immediately prior snapshot of the same data from ~15 seconds ago ("previous"). Note that we
-- include a dummy row with a fake spid number for any DACs that don't have any active sessions. This
-- is because of a downstream requirement that we return a row for all DACs, even if there are no stats
-- to report for the DAC.
INSERT INTO dbo.sysutility_mi_session_statistics_internal
(collection_time, session_id, dac_instance_name, database_name, login_time, cumulative_cpu_ms)
SELECT
@current_collection_time,
ISNULL (sp.spid, -10) AS session_id,
#dacs.dac_instance_name,
#dacs.database_name,
ISNULL (sp.login_time, GETDATE()) AS login_time,
ISNULL (SUM(sp.cpu), 0) AS cumulative_cpu_ms
FROM #dacs
LEFT OUTER JOIN sys.sysprocesses AS sp ON #dacs.database_id = sp.[dbid]
GROUP BY ISNULL (sp.spid, -10), #dacs.dac_instance_name, #dacs.database_name, ISNULL (sp.login_time, GETDATE());

-- Step 2: If this is the first execution, set @prev_collection_time to @cur_collection_time.
-- This has the effect of generating stats that indicate no work done for all DACs. This is
-- the best we can do on the first execution because we need to snapshots in order to calculate
-- correct resource consumption over a time interval. We can't just return here, because we
-- need at least a "stub" row for each DAC, so they all DACs will appear in the UI if a DC
-- upload runs before our next collection time.
IF (@previous_collection_time IS NULL)
BEGIN
SET @previous_collection_time = @current_collection_time;
END;

-- Step 3: Determine the amount of new CPU time used by each DAC in the just-completed ~15 second interval
-- (this defines a CTE that is used in the following step).
WITH interval_dac_statistics AS (
SELECT
#dacs.dac_instance_name,
-- Add up the approximate CPU time used by each session since the last execution of this proc.
-- The [current CPU] - [previous CPU] calculation for a session will return NULL if
-- [previous CPU] is NULL ([current CPU] should never be NULL). Previous CPU might be
-- NULL if the session is new. Previous CPU could also be NULL if an existing session
-- changed database context. In either case, we will not charge any of the session's
-- CPU time to the database for this interval. We will start charging any new session
-- CPU time to the session's current database on the next execution of this procedure,
-- assuming that the session doesn't change database context between now and then.
SUM (ISNULL (cur.cumulative_cpu_ms - prev.cumulative_cpu_ms, 0)) AS interval_cpu_time_ms,
#dacs.database_name,
#dacs.database_id,
#dacs.date_created,
#dacs.[description]
FROM #dacs
LEFT OUTER JOIN dbo.sysutility_mi_session_statistics_internal AS cur -- current snapshot, "right" side of time interval
ON #dacs.dac_instance_name = cur.dac_instance_name AND cur.collection_time = @current_collection_time
LEFT OUTER JOIN dbo.sysutility_mi_session_statistics_internal AS prev -- previous snapshot, "left" side of time interval
ON cur.dac_instance_name = prev.dac_instance_name AND prev.collection_time = @previous_collection_time
AND cur.session_id = prev.session_id AND cur.login_time = prev.login_time
GROUP BY #dacs.dac_instance_name, #dacs.database_name, #dacs.database_id, #dacs.date_created, #dacs.[description]
)

-- Step 4: Do an "upsert" to the staging table. If the DAC is already represented in this table, we will
-- add our interval CPU time to that row's [lifetime_cpu_time_ms] value. If the DAC does not yet exist
-- in the staging table, we will insert a new row.
--
-- A note about overflow risk for the [lifetime_cpu_time_ms] column (bigint). A DAC that used 100% of
-- every CPU on a 500 processor machine 24 hours a day could run for more than half a million years without
-- overflowing this column.
MERGE [dbo].[sysutility_mi_dac_execution_statistics_internal] AS [target]
USING interval_dac_statistics AS [source]
ON [source].dac_instance_name = [target].dac_instance_name
-- Filter out "orphaned" DACs that have had their database deleted or renamed
AND DB_ID([target].database_name) IS NOT NULL

WHEN MATCHED THEN UPDATE
SET [target].lifetime_cpu_time_ms = ISNULL([target].lifetime_cpu_time_ms, 0) + [source].interval_cpu_time_ms,
[target].last_collection_time = @current_collection_time,
[target].first_collection_time = ISNULL ([target].first_collection_time, @previous_collection_time),
[target].database_name = [source].database_name,
[target].database_id = [source].database_id,
[target].date_created = [source].date_created,
[target].[description] = [source].[description]

WHEN NOT MATCHED BY TARGET THEN INSERT ( -- new DAC
dac_instance_name,
first_collection_time,
last_collection_time,
last_upload_time,
lifetime_cpu_time_ms,
cpu_time_ms_at_last_upload,
database_name,
database_id,
date_created,
[description])
VALUES (
[source].dac_instance_name,
@previous_collection_time,
@current_collection_time,
@previous_collection_time,
[source].interval_cpu_time_ms,
0,
[source].database_name,
[source].database_id,
[source].date_created,
[source].[description])

WHEN NOT MATCHED BY SOURCE THEN DELETE; -- deleted or orphaned DAC

-- Step 5: Delete the session stats from the previous collection time as we no longer need them (but keep the
-- current stats we just collected in Step 1; at the next collection time these will be the "previous"
-- stats that we'll use to calculate the stats for the next interval).
DELETE FROM dbo.sysutility_mi_session_statistics_internal WHERE collection_time != @current_collection_time;
END;
17 авг 12, 13:12    [13026223]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
HandKot
Member

Откуда: Sergiev Posad
Сообщений: 3041
мне кажется здесь ищите
INSERT INTO dbo.sysutility_mi_session_statistics_internal 
(collection_time, session_id, dac_instance_name, database_name, login_time, cumulative_cpu_ms)
 SELECT 
@current_collection_time, 
ISNULL (sp.spid, -10) AS session_id, 
#dacs.dac_instance_name, 
#dacs.database_name, 
ISNULL (sp.login_time, GETDATE()) AS login_time, 
ISNULL (SUM(sp.cpu), 0) AS cumulative_cpu_ms
 FROM #dacs 
LEFT OUTER JOIN sys.sysprocesses AS sp ON #dacs.database_id = sp.[dbid]
 GROUP BY ISNULL (sp.spid, -10), #dacs.dac_instance_name, #dacs.database_name, ISNULL (sp.login_time, GETDATE()); 
17 авг 12, 13:43    [13026449]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
Alex5555555555
Member

Откуда:
Сообщений: 114
HandKot,
спасибо всем, разобраться не разобрался, но тормознул план обслуживания и заработал джоб
17 авг 12, 13:45    [13026466]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
HandKot
Member

Откуда: Sergiev Posad
Сообщений: 3041
Alex5555555555
HandKot,
спасибо всем, разобраться не разобрался, но тормознул план обслуживания и заработал джоб


ну а чего там разбираться?
видать план обслуживания настолько отожрал процессора, что значение не влезало в int
поменяйте на bigint или decimal
17 авг 12, 13:51    [13026532]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
Alex5555555555
Member

Откуда:
Сообщений: 114
HandKot,

это очевидно, спасибо








блог
17 авг 12, 14:05    [13026635]     Ответить | Цитировать Сообщить модератору
 Re: Запуск процедуры средствами Jobs  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
Alex5555555555
лайн 40....пустая, подскажите может быть
Как пустая??? Что то вы путаете.
INSERT INTO dbo.sysutility_mi_session_statistics_internal 
 (collection_time, session_id, dac_instance_name, database_name, login_time, cumulative_cpu_ms)
17 авг 12, 14:14    [13026710]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить