У меня есть весеннее пакетное задание, которое копирует данные из таблиц из одной схемы оракула в другую.Для этого я написал разделенную работу.Например:
Случай A:
У меня есть таблица A с 100000 строк, и я разбил на 100 шагов по 1000 строк в каждой.Все эти вставки выполняются параллельно с помощью исполнителя задач ThreadPool.Если 4 шага не удалось из-за какой-то проблемы.Я перезапустил задание, оно успешно выполнило 4 неудачных шага в течение нескольких секунд, как я и ожидал.
Случай B:
Скажем, таблицу A, содержащую 32 миллиона строк, необходимо скопировать из источника в место назначения.Поэтому я разделил это задание на шаги по 1000 строк в каждом, чтобы было создано 32000 шагов.
Из этих 32000 шагов 4 шага не выполняются из-за некоторой проблемы с БД.Когда я пытаюсь перезапустить эту работу, Spring batch просто зависает, или я не знаю, что происходит после перезапуска, он просто ничего не делает.Я ждал 5 часов, а затем убил работу.
так может кто-нибудь помочь мне с тем, что происходит после перезапуска, как общее количество шагов влияет на перезапуск?и что я должен сделать, чтобы улучшить эту скорость?
Пожалуйста, дайте мне знать, если требуется дополнительная информация.
Обновления:
Я смогчтобы ускорить Случай B, реализовав PartitionNameProvider и возвращая имена неудачных шагов в одиночку через getPartitionNames во время перезапуска.Отлично.Я тестировал этот перезапуск с большим количеством сбоев, и сейчас у меня есть еще один случай.
Случай C:
Если у меня 20000 шагов и все 20000 шагов не пройдены.Когда я пытаюсь перезапустить это дело.getPartitionNames возвращает все 20000 шагов.В этом случае я сталкиваюсь с проблемой, о которой я упоминал выше.Процесс зависает.
Я попытался понять, что происходило за заданием, включив журналы весенней отладки (что заняло у меня так много времени, но оно того стоило).Я видел определенный набор запущенных запросов.они:
2019-02-22 06:40:27 DEBUG ResourcelessTransactionManager:755 - Initiating transaction commit
2019-02-22 06:40:27 DEBUG ResourcelessTransactionManager:39 - Committing resourceless transaction on [org.springframework.batch.support.transaction.ResourcelessTransactionManager$ResourcelessTransaction@5743a94e]
2019-02-22 06:40:27 DEBUG ResourcelessTransactionManager:367 - Creating new transaction with name [org.springframework.batch.core.repository.support.SimpleJobRepository.getLastStepExecution]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2019-02-22 06:40:27 DEBUG JdbcTemplate:682 - Executing prepared SQL query
2019-02-22 06:40:27 DEBUG JdbcTemplate:616 - Executing prepared SQL statement [SELECT JOB_EXECUTION_ID, START_TIME, END_TIME, STATUS, EXIT_CODE, EXIT_MESSAGE, CREATE_TIME, LAST_UPDATED, VERSION, JOB_CONFIGURATION_LOCATION from COPY_JOB_EXECUTION where JOB_INSTANCE_ID = ? order by JOB_EXECUTION_ID desc]
2019-02-22 06:40:27 DEBUG DataSourceUtils:110 - Fetching JDBC Connection from DataSource
2019-02-22 06:40:27 DEBUG DataSourceUtils:114 - Registering transaction synchronization for JDBC Connection
2019-02-22 06:40:27 DEBUG JdbcTemplate:682 - Executing prepared SQL query
2019-02-22 06:40:27 DEBUG JdbcTemplate:616 - Executing prepared SQL statement [SELECT JOB_EXECUTION_ID, KEY_NAME, TYPE_CD, STRING_VAL, DATE_VAL, LONG_VAL, DOUBLE_VAL, IDENTIFYING from COPY_JOB_EXECUTION_PARAMS where JOB_EXECUTION_ID = ?]
2019-02-22 06:40:27 DEBUG JdbcTemplate:682 - Executing prepared SQL query
2019-02-22 06:40:27 DEBUG JdbcTemplate:616 - Executing prepared SQL statement [SELECT STEP_EXECUTION_ID, STEP_NAME, START_TIME, END_TIME, STATUS, COMMIT_COUNT, READ_COUNT, FILTER_COUNT, WRITE_COUNT, EXIT_CODE, EXIT_MESSAGE, READ_SKIP_COUNT, WRITE_SKIP_COUNT, PROCESS_SKIP_COUNT, ROLLBACK_COUNT, LAST_UPDATED, VERSION from COPY_STEP_EXECUTION where JOB_EXECUTION_ID = ? order by STEP_EXECUTION_ID]
2019-02-22 06:40:27 DEBUG JdbcTemplate:682 - Executing prepared SQL query
2019-02-22 06:40:27 DEBUG JdbcTemplate:616 - Executing prepared SQL statement [SELECT STEP_EXECUTION_ID, STEP_NAME, START_TIME, END_TIME, STATUS, COMMIT_COUNT, READ_COUNT, FILTER_COUNT, WRITE_COUNT, EXIT_CODE, EXIT_MESSAGE, READ_SKIP_COUNT, WRITE_SKIP_COUNT, PROCESS_SKIP_COUNT, ROLLBACK_COUNT, LAST_UPDATED, VERSION from COPY_STEP_EXECUTION where JOB_EXECUTION_ID = ? order by STEP_EXECUTION_ID]
2019-02-22 06:40:30 DEBUG JdbcTemplate:682 - Executing prepared SQL query
2019-02-22 06:40:30 DEBUG JdbcTemplate:616 - Executing prepared SQL statement [SELECT SHORT_CONTEXT, SERIALIZED_CONTEXT FROM COPY_STEP_EXECUTION_CONTEXT WHERE STEP_EXECUTION_ID = ?]
2019-02-22 06:40:30 DEBUG JdbcTemplate:682 - Executing prepared SQL query
2019-02-22 06:40:30 DEBUG JdbcTemplate:616 - Executing prepared SQL statement [SELECT SHORT_CONTEXT, SERIALIZED_CONTEXT FROM COPY_JOB_EXECUTION_CONTEXT WHERE JOB_EXECUTION_ID = ?]
2019-02-22 06:40:30 DEBUG DataSourceUtils:327 - Returning JDBC Connection to DataSource
и так далее ...
Я понял, что spring выполняет getLastStepExecution для каждого неудачного шага один за другим.Но почему getLastStepExecution делается таким образом?или есть ли способ настроить это?например, чтение всех пошаговых выполнений и начало обработки, чтобы сократить время перезапуска.
Заранее спасибо.