#####1 an error occurred while loading odoo
######2 first check the configuration file, especially the path
######3, and then enter – I base – D new database name in run/debug configurations
#####4 restart the server to see if it is OK. If not, reinstall the database and change the version of the database. If not, reload the source code. The source code may have been accidentally changed
After reading, remember to like it, refill
Many odoo users have encountered the problem that the backed up database cannot be restored
You can self-check in the following ways
1. Is the odoo version correct? Different versions of odoo cannot be restored directly, for example, odoo13 cannot be restored directly to odoo15
2. Whether the database version is correct, postgres may have problems when it is backward compatible. It is recommended to migrate to the same version.
3. Whether the code is migrated correctly, inconsistent codes on both sides will also cause an error, which is common in the conf file without specifying the code location.
If you confirm that the above content is correct, you can try the following methods
1. Add -d database name -i base when starting odoo through the command line, this method is to select the database to force the update of the base module; because all odoo modules are dependent on this, the mandatory update will be all the modules installed in the database after the base Will be upgraded.
2. Enter postgres, enter the following command
su postgres; # Switch postgres users
psql; # Enter the postgres command line
\c; database name # specify database instance
DELETE FROM ir_attachment WHERE url LIKE '/web/content/%'; # Delete the front-end files cached in the data tableGenerally, most problems can be solved through the above two steps.
The Postgres version of this tutorial case is 12
Problem Description:
psycopg2.OperationalError: FATAL: sorry, too many clients already onIn the morning, I found that the python back-end service I maintained reported an error. Baidu found that the default maximum concurrency of Postgres was only 100, which led to this problem
Modify tutorial:
cd /var/lib/postgresql/12/main
vi postgresql.auto.conf
Add the following line of code to the file to set the maximum number of connections to 800, the default is 100
max_connections = 800
Restart the service
service postgresql restartThe following is the SQL command to check whether the modification is successful:
# Show the maximum number of connections to the current database
show max_connections;
# Show the number of users currently connected to the data
SELECT COUNT(*) from pg_stat_activity;
# Show details of the current connection, very slow, don't use it
SELECT * FROM pg_stat_activity;
The effect is similar, which indicates that the setting is successful
solution:
the first step: look at the journal CD $ORACLE_BASE/diag/RDBMS/zdzrac/zdzrac1/trace; Tail – 200 alert_zdzrac1. The log
note: 200 represents the display of 200 lines
CTL ‘,’/ disk2/ control01.ctl’, ‘/disk3/control03.ctl’,’/disk3/control03.ctl’ scope=spfile; Causes the control file path to change
step 3: find the path of the original control file on another normal node
SQL> select status,name from v$controlfile;
the STATUS of the NAME
——————————————————————————–
+ DATA/zdzrac controlfile/current. 256.947408805
step 4: modify the control file path in the spfilec parameter file to solve the problem
oracle# create pfile = ‘/ u01/app/oracle/product/11.2.0.4/dbhome_1/DBS/init0714 ora’ from spfile = ‘/ u01/app/oracle/product/11.2.0.4/dbhome_1/DBS/spfilezdzrac1 ora’;
oracle# vi/u01/app/oracle/product/11.2.0.4/dbhome_1/DBS/init0714 ora
zdzrac2.__db_cache_size=2801795072
zdzrac1.__db_cache_size=2801795072
zdzrac2.__java_pool_size=16777216
zdzrac1.__java_pool_size=16777216
zdzrac2.__large_pool_size=33554432
zdzrac1.__large_pool_size=33554432
zdzrac1.__oracle_base=’/u01/app/oracle’#ORACLE_BASE set from environment
zdzrac2.__oracle_base=’/u01/app/oracle’#ORACLE_BASE set from environment
zdzrac2.__pga_aggregate_target=838860800
zdzrac1.__pga_aggregate_target=838860800
zdzrac2.__sga_target=3539992576
zdzrac1.__sga_target=3539992576
zdzrac2.__shared_io_pool_size=0
zdzrac1.__shared_io_pool_size=0
zdzrac2.__shared_pool_size=654311424
zdzrac1.__shared_pool_size=654311424
zdzrac2.__streams_pool_size=0
zdzrac1.__streams_pool_size=0
*.audit_file_dest=’/u01/app/oracle/admin/zdzrac/adump’
*.audit_trail=’db’
*.cluster_database=true
*. Compatible = ‘11.2.0.4.0’
*. Control_files = ‘+ DATA/zdzrac controlfile/current 256.947408805’// change control file path
*.db_block_size=8192
*.db_create_file_dest=’+DATA’
*.db_domain=”
“/ u01/app/oracle/product/11.2.0.4/dbhome_1/DBS/init0714 ora” 44 l, 1489 c
step 5: restart the database using the pfile file
startup pfile = ‘/ u01/app/oracle/product/11.2.0.4/dbhome_1/DBS/init0711 ora’;
step 6: create the spfile file with the modified pfile
SQL> The create spfile from pfile = ‘/ u01/app/oracle/product/11.2.0.4/dbhome_1/DBS/init0714 ora’ ‘;
step 7: close the database and start the database
SQL> shutdown immediate
SQL> startup
[ORA] Error 1031 Received logging on to the standby
Scene:
When building Windows Server 2008 R2 single-instance DG connected to Linux RAC (11.2.0.3), an error was reported on node 2:
Error 1031 received logging on to the standby
Solution:
The password file will be the same if you use Oracle as the password, but it turns out that you still need to recreate the password file, and the password file will be identical in all three places.
orapwd file=orapworcl password=oracle;
generated the password file; So just copy the password file from node 1 to node 2 and DG (change the file name to PWD instance name.ora, in this case pwdorcl.ora). If you check the alter log and it still gives an error, you need to redistribute and cancel the log application before starting the application log.
*** stop redo logging application
SQL> alter database recover managed standby database cancel;
*** open real-time logging application
SQL> alter database recover managed standby database using current logfile disconnect;