we have a db2 11.1.4.4 database on centos 7, file system format is xfs and the size of database is 50 TB. Sometimes it takes too long time (1-2 hours) to activate the database, instance memory usage at the time when the activate command is running is less than 10 percents of its configured value, disk I/O is ok and there is no message in db2diag.log and server log, what causes this problem?
edited:
Our database is HADR and sometimes when we have stopped the database and we want to activate it, we encounter this problem on both of primary and standby.
Thanks
Too many primary log files could slow down your DB activation as well.
Related
Background:
I've been tasked with importing a large amount of data from a production database to a test database (Oracle 12c release 2 running on RHEL) and I'm using Data Pump.
The first time I imported the tables, The tables were created and the data was imported as planned, but - due to an issue in my data pump parameter file - the constraints were not imported.
My subsequent attempts did not go as well, however. Data Pump began to freeze part way and the STATUS command showed that no bytes were being processed.
My Solution Attempts:
I tried using TABLE_EXISTS_ACTION=REPLACE and dropping the tables directly after an attempt. I also dropped the master tables of any data pump jobs I was unable to terminate from the utility.
Still, it seemed to hang earlier and earlier in the process as I continuously tried to import the tables. df -h returned 100% disk usage every time it hanged.
The dump file itself is on a separate drive so it's no longer taking up room. I've been trying to clear out space but it keeps filling up when I run a job and I can't tell where. Oracle flashbacks are disabled and I made sure to purge the oracle recycle bin.
tl;dr:
Running impdp jobs seems to use up disk space beyond the added tables and the job master tables. Where is this memory getting used up and what can I do to clear it for a succesful import?
I figured out the problem:
The database was in archivelog mode in order to set up streams and recovery manager backups. As a result, impdp was causing a flood of archived database changes.
In order to clear out the old archives I ran the following in rman for every database in noarchivelog mode on the server.
connect target /
run {
allocate channel c1 type disk;
delete force noprompt archivelog until time 'SYSDATE-30';
release channel c1;
}
This cleared up 60 gigabytes. I also added the parameter transform=disable_archive_logging:Y to my impdp parameter file. This suppresses archive creation when running data pump imports.
I have used Hp Vertica 7.0
It sometimes slowed down. (select count(*) from sessions ; returns : 250 )
When I checked system monitor on centos which the vertica is installed on ,
there is not huge load on the machine. I want to know the db is work on in memory?
it comes by default or should I set it in paramaters table?
thanks in advance
This means that you have 250 programs currently connected with your Vertica cluster.
Every connection uses memory and other resources, even if it is idle.
To see how many processes are active, you might go:
SELECT
COUNT(*) as active_request_count
FROM query_requests
WHERE is_executing;
And, by all means, verify how many of the 250 connections / sessions are really needed, and close all sessions that are not needed.
Maybe, if you can, it's easiest to shut down and restart the database.
Good luck
Marco
Whenever I am inserting a key in any one db of the redis cache, it gets inserted in all 16 dbs and removing the key from any one db deletes the same from all DBs. Attached is the screen shot showing the same. As per my knowledge, the DBs are independent of each other and at a time any key should be inserted/removed from the current DB in use. Could anyone please explain the observed behaviour?
The Azure Redis Portal Console currently doesn't handle the Select statement correctly (because each command goes out on a new connection), so you are actually doing a get on DB 0. This is a known issue and we are in the process of creating the V2 of the portal console, which will fix this issue. Rough ETA is sometime in the next couple of months.
I am using Attunity Oracle drivers to connect to Oracle Database on a remote server to retrieve data and dump into Excel File.
Everything works fine in Visual Studio BIDS. From VS I can connect directly to remote Oracle server and retrieve the data.
But when i deploy this ETL to my production server (64 Bit Windows Server 2008 & SQL Server 2012), ETL is always get stuck at Execution phase. After running for some time (20-30 mins), it gives following warning & still keeps running without giving any errors -
[SSIS.Pipeline] Information: The buffer manager detected that the system was low on virtual memory, but was unable to swap out any buffers. 0 buffers were considered and 0 were locked.
Either not enough memory is available to the pipeline because not enough is installed, other processes are using it, or too many buffers are locked.
Some more info -
I have checked server memory, only 3GB is in use out of total 12GB.
I have already set SQL server to use max 8GB.
I am using SQL Server Agent job to run the ETL periodically every 15 mins.
I have tried stopping all other ETLs on the server and tried running this ETL through Execute Package Utility but still the result is same.
I am using a date range in Oracle Query to retrieve the data, when the query for a particular date range does not return any data, ETL execution is always successful !!.
Progress log (Execute Package Utility) -
Any pointers/suggestion ??
Hope I am able to describe the issue properly.
Update (5/Mar/2014) -
I tried reducing the amount of data I am retrieving, and the ETL was successful.
I have also set the DefaultBufferSize to 10 MB(Max size).
But if the query data is exceeding DefaultBufferSize then why the package is successful on my development machine but not on the server ??
Thanks,
Prateek
I built a chat application in which chatting page is loaded per every 1second through AJAX,
And i used DB2 express-c database for storing messages.
one day 500 user at a time used this app at a that time database is stopped working.
Is their any effect on database by running 500 quires at a time in one second.
please tell how to run quires for every second without effecting the database functionality.
The red mark on the DB2 icon means that the instance stop working. This issue should be related to a memory problem or something else.
You have to check the db2diag.log file, and check for message. It is highly probable that you have information at the time when the instance stopped. The first failrue data capture feature allows to recopile all that information when a crash occurs, in the diag directory.
In order to fix the problem, you just need to restart DB2. You can create a task that check if the instance is up, and if not, try to restarted. However, this is the wrong way to keep DB2 up.
You should see what happened at the time when DB2 crashed. Probably, the memory for the 500 agents was too high, and DB2 could not reserve more memory.
Are you running other processes in the same DB2 server? probably one of them corrupt the DB2 memory.