Got this Error...
TF30042: The Database is Full. Contact your Team Foundation Server administrator.
Error:1101, Message: could not allocate a new page for database 'Tfs_DefaultCollection' because of insufficient disk space in filegroup 'PRIMARY'. Create the necessary space by dropping objects in the filegroup, adding additional files to filegroup, or setting autogrowth on for existing files in the filegroup.
How to increase size of TFS 2018 database ? Don't have UI to check size and all on server how to change database config through command line?
There is no tool that ships with TFS to alter the files. But any SQL Server management tool will work. I generally use SQL Server management studio to either change the database files directly or to generate the script to change the file size.
Using sqlcmd you can open an interactive session to the database that your TFS server stores all its data in. You can then issue an ALTER DATABASE statement to change the max size of the database.
ALTER DATABASE tfs_defaultcollection
MODIFY FILE
(
NAME = PRIMARY,
SIZE = 50MB
);
Set the new size in the statement above to be big enough. Alternatively, enable auto-growth by setting SIZE = UNLIMITED.
Related
My instructor gave me a username and password and .dbf file and tell me to open it and try to retrieve with sqlplus and oracle database
I tried to open the dbf file from excel mysql and ms server but it i gave me an error
Speaking as a DBA: As Littlefoot stated, you can't just read a data file from an Oracle DB. At best they are proprietary binary file formats, assuming it isn't encrypted on top of that. Nor can you take a data file from one database instance and just plug it in to another database instance. You also can't import it to mySQL or any other database engine: as a stand-alone data file it can only be properly read by its original database installation (i.e. the specific database instance that created it).
Oracle has specific tools available to copy data and/or files from one database to another, but those would generally use the RMAN backup manager (used to make physical backups) or (more likely in your case) the Datapump "Transportable Tablespace" feature.
To restore it from an RMAN backup you would need a complete full backup of the entire source database instance: RMAN backup sets including all data files, redo logs (and perhaps archived logs), control files, parameter files, encryption keys,, and possibly more.
To restore a transportable tablespace dump you would need your own running Oracle database instance, the correct parameters to run the impdp import utility, and the assistance/cooperation of the DBA.
You need to confirm if the file you were given is such an export dump (though the .dbf file extension would suggest not), and how you are expected to access the data. You won't be able to just "open the file".
.DBF extension probably represents datafile; I don't think you can read it with any tool (at least, I don't know of any).
You should find an Oracle DBA who might try to help; in order to restore a database (which is contained in that file), they might need control file(s), redo log files and ... can't name what other files (I'm not a DBA).
Then, if everything goes OK, database might be started up so that you'd be able to connect to it using credentials you were given.
my server had been attacked by a ransomware .rapid and all my data had been encrypted , luckily for me the oracle home folder is not encrypted - yet - and most of the files including the datafiles folder and tablespaces are still accessible
Can any One please tell me how to recover my database objects?
no backup is available , only oracle home folder -most of it-
EDIT :
The System is broken , I am trying to know witch files to collect and copy that will enable me to recover my database files from another system
when I try to log into sqlplus throw cmd I get the following error :
'sqlplus' is not recognized as an internal or external command ,
operable program or batch file.
Blockquote
EDIT :
FILES THAT I STILL HAVE ACCESS TO - NOT ENCRYPTED -
Okay. If you can find an init.ora file on your server, that's the PFILE - initialization parameter file - that's the last thing missing to easily copy your database to a new server. If you can't find it, that's ok - it'll just be a little harder. As long as you have the datafiles, you can eventually get your database back.
Basically, you'll want to follow steps 2-8 in the link I posted. You can also find some helpful info in the Oracle guide to manually creating a database in Windows. I'll walk you through them.
Shutdown your old database (if it's still running). This will make sure your datafiles are in a consistent state for copying. Probably stopping the Windows Service would be the easiest way to do that if you can't access sqlplus.
Copy the data to your new server. I'm assuming it'll be in the same location, D:\app\Administrator\oradata\VTC\
Make a copy of the control file CONTROL01.CTL and name it create_db.sql (EDIT: I was assuming that this was a backup to trace ascii version of the control file, but it sounds like this is the binary file)
Edit create_db.sql. Where it says CREATE CONTROLFILE REUSE DATABASE "MY_DB" NORESETLOGS, change it to CREATE CONTROLFILE SET DATABASE "MY_DB" RESETLOGS. Make note of whatever "MY_DB" is - this is your database name. Most people make it the same as the SID. I normally do RESETLOGS which throws out the old redo logs, but you could try keeping them with NORESETLOGS if that works for you.
Remove or comment out the lines that say RECOVER DATABASE and ALTER DATABASE OPEN;. Make sure the paths for the datafiles and logfiles look correct. Save the file.
If you couldn't find your init.ora to copy, I think this very minimal one will work for you, although you'll want to fix your memory settings later. Create it in the same folder.
DB_NAME=MY_DB
INSTANCE_NAME=MY_DB
SERVICE_NAMES=MY_DB
CONTROL_FILES = ("D:\app\Administrator\oradata\VTC\CONTROL01.CTL")
DB_FILES=100
Create an Oracle Database Windows Service. Afterwards check Services to make sure it's running.
oradim -NEW -SID MY_DB -STARTMODE manual -PFILE "D:\app\Administrator\oradata\VTC\init.ora"
Log in to your new Oracle instance as SYSDBA. There's no database yet.
cd D:\app\Administrator\oradata\VTC\
set ORACLE_SID=MY_DB
sqlplus / as sysdba
Create the database, using the control file from the old server as a script.
#create_db.sql
If everything comes back OK, run:
alter database open
is there any way to drop objects and packages of a schema in ORACLE DB without generating archive logs?
i have a huge schema that is decommissioned. i want to drop all its objects first but it generates a lot amount of archive logs which filled my Fast Recovery Area.
please help if you know any solution to the objects of a schema without generation of archive logs.
i tried to use drop for example:
drop package xyz it generated a lot of archive logs.
note:
the database server is holding both active and non active schemas all what i need is to drop the old non active schemas without generating archive logs.
Thank you in advance,
Wissam.
If the system is really going to be decommissioned then you can alter the system and set off archive mode at first place and then start dropping the objects.
The method for disabling archive log mode is:
Shutdown edit pfile / spfile (spfile when instance is up ofcourse) to say log_archive_start = false.
startup mount
alter database noarchivelog;
alter database open;
Read more at here.
I'm running into a problem while linking some tables and views present on a Oracle 11g database to a Access 2007 file.
I'm using the Oracle Client (SQORA32.DLL) version 11.02.00.03.
If the view/table returns a small amount of data, there's no problem. The problem happens when the view or the table returns a "large" amount of data. I've tried to increase the buffer size on the driver (default is 64000) to see if that happens. I've also removed the "Enable query timeout" option - otherwise I would get a "Query cancelled by user" or a "ODBC - Call Failed" error.
In order to link the tables/views, I've used the "native tool" (External Data -> ODBC Database -> Link to data source by creating a linked table).
I was wondering if I could retrieve the data from the tables/views using vba. Sometimes, I (you should read "I" as "the users") may need to update data on some tables (control tables).
Please let me know your thoughts.
EDIT: Our goal with this project was to migrate from SQL Server 2005 to Oracle 11gR2. After analyzing the behaviour of the Access files regarding the SQL Server, I've concluded that the results are showing like a "cursor" - if you scroll down on the result window, it will load more.
I think that this may be the issue because, AFAIK, Oracle (driver, maybe?) pulls everything from the DB and, only then, populates MS Access.
It's a long time after this so here goes the solution. MS access has a flag for the ODBC connection as "Treat Float as Numeric". This have made the trick.
How can I duplicate an Oracle instance? Does anyone have any idea how to do so?
Assuming you want the schema and data duplicated, use the exp and imp commands to export your database, then import it as another user using the FROMUSER and TOUSER parameters.
Well, presumably you have a backup (surely!), so just test your backup recovery on your test server.
To be slightly more serious, it depends what version you are using, newer versions of RMAN make it pretty easy I believe, older versions, you basically do it as a backup recover.
How I've done it in the past, is basically
copy backup data files
create init file
create a new controlfile is the command 'CREATE CONTROLFILE SET DATABASE "TEST" RESETLOGS ARCHIVELOG'
Apply archivelogs and then open with resetlogs
Here is an article which explains the process with a bit more detail
A minor comment on your terminology - "instance" is actually the set of processes running on the database server host and you want to duplicate the "database".
As someone else mentioned, the best way is to start with an RMAN backup of the original database. However, since Oracle 9 RMAN has had the "DUPLICATE DATABASE" command, which takes care of a lot of housekeeping that used to be necessary if you just made a copy by restoring a production backup (e.g. resetting DBID, changing data and log file locations in the control file, setting database GLOBAL_NAME, etc.).
If you're not using RMAN, and the database is on the small side, you can script something that puts each tablespace in hot backup mode, copies the datafiles for that tablespace to a backup location, and then takes the tablespace out of hot backup mode. You now have a recoverable backup that can be moved to another host for archive log application. This definitely has a performance impact on the original database and should be your last resort.
Create a template based on your existing instance. You can then create other instances.