nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Slow startup of alfresco after switching databases

AidenZ

Hi everybody
I'm currently using alfresco 7.3 in enterprise version.
This was working fine before, but when I switched databases (which were previously used by other versions of alfresco) and restarted content, alfresco's content startup became incredibly long.
In fact, I waited for about two hours, and all that time the startup became slow and the db's cpu became high.
When I went to restart the content service again after waiting all night, the time dropped to five to ten minutes at that point.
This seems to be back to the status quo, but I have absolutely no idea what happened during that time and what caused it to start up incredibly slow when switching databases in the first place...
Can anyone tell me the answer please?

Find more posts tagged with

Alfresco Content Services

Comments

grathod

Dear AidenZ,

You switched database, so I assume you also sync "contentstore" and "database" [ cold backup ]

see solr indexes can be built automatically, gradually but above two thing need to be in sync.

and assuming you are using compatible db version according to Supported Platform

Thanks,

Ghanshyam

AidenZ

Dear Ghanshyam

Thanks for your reply, I don't think that such a long startup time is caused by both.
As a matter of fact, I did do this kind of file migration.
After I switch the 7.3 version of alfresco to an older version of db that has been running for a while and then start it up, I get the 'Found item in transactional cache' log, maybe this is related to the transactional cache, but I'm not sure why changing the db would re-execute the transactional cache query.

Thanks,

Aiden