DPM transfer block size

I am setting a DPM 2010 and am using a MSA 2000 for storage. The MSA best practice suggest setting up the virual disk chunk size to match the transfer block size of the application using it. Available chunk size include: 16 Kbyte, 32 Kbyte,
64 Kbyte. 64 Kbyte is the default on the MSA. Does anyone know what DPM transfer block size is?

DPM requests the data size at file system level, so there are many layers before it reaches storage/hardware devices so it may get changed at any place. In any case most of the DPM operations are at 16Kbytes block size.Thanks, Praveen D [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

Similar Messages

Raid 0 (Stripe) for OS X boot disk? Best Performance and block size

Hi,
so this is a new thread to an older question I had and would like some feedback on;
I have a new Mac Pro with 4 matched 1TB caviar black drives. I WILL be doing Full Time-Machine Backups, as well as an independant full-system backup regularly.
That being said, I have 4 drives open and am looking for suggestions. I am leaning toward 2 sets or stripes (one for the OS and one for 'work space', the former with a 32k stripe block size, the latter with 64k (will hold video, audio, scratch, and, yes, Games).
Does this sound alright? Is there an issue with Striping the boot drive? Is the block size or 32 (or 64) optimal?
Thanks!
Dan

Hi D# Shooter, regarding your question,
D3 Shooter wrote:
You brought to mind something I did not take into consideration, Time Machine. I really like the simplicity of TM as it saved me once before. So, could you tell me, for photo files, some video, how much does the striping (% wise) improve the accessing and filing of such files compared to no striping but, using internal drives (7200/WD/1TB/Caviar)? I have not done striping before and want to weigh in because of the back up storage issues now. Thanks.
J_ust give it a try and see if it is worth it for you_.
Striping:
• just enhances (reduces the access/transfer) because in practice the access is distributed in parallel across several DDM's (Old school but it works great!). I think for video and file work the advantage is that you can access the whole object sooner (rather than faster).
• this distribuition also reduces a load of old style queing on the device ove rthe path. THis was resolved in the late 1980's so no reall rocket science here.
the issues with striping are few and basically over all the raid implementations (except JBOD which of course is not raid) when compared to a single spindle. The discussions are enormous and plentiful via google and experiences and opinions vary widely.
Fir the I.T. peole its the advantage they get for access using a smart disk controller that caches goosies like indexes and stuff so that they can sustain a zillion trivial transactions/sec (i.e. banking & internet stuff).. stuff that is of no interest to me
For the creative people and many applications that are BLOB's (like video, film and remote sensing objects) getting use of the objects sooner (not faster) is of prime importance for workflow efficiencies. If you have this need then striping stiff across disks is for you!
TIMEMACHINE.app works fine as it seems fairly agnostic to whats implemented under the disk file system. MY issue with time machine is that I don't want it looking after my production stuff, only to keep an eye on my admin I.T. type stuff such as ~/ and data data files.
As posted on ths thread:
• availability is the major concern with any file system (cloud or raid or other). RAID with parity schemes and double parity schemes (Raid1,,3,5,6) and implementations such as RAID6+ LSF (log structured file) are all wonderful for this business workflows that need it.
• timely access in a workflow is another
• cost benefits are another
However a *great benefit* for me of *consolidating small storage components under one huge file system is that you dont have to COPY any thing around*. THis is marvelous especially when you think you have to move 2TB's of stuff from one place to anther. THis a takes a lot of time with elcheapo didks that dont have fast interfaces such as SATA/SAS of FC for example.
As always and has been addressed by others on this thread (Hatter) if you lose a component storage device the whole file system is hosed or severely degraded unless you spend a lot of money on full ranks of DDMs with hot spares and a very good RAID controller card. Again its money.
YEah sure you can carry some PARITY RAID implementation around across 3 didks but the storage capacity usage is dreadful. THis is why more complex RAID implemntatiosn are in groups of 10+ dDMs.. (yep poepl can argue.. but this is the mainstream).
My external disk arrays are merely two LUNs (SAS DOMAINSA) that have two file systems implemented using 2 x 4TB 1TBs DDMS - all RAID0 - no parity (no availability) - I just want speed. I look after my own "availability" withm= my archive solution. If the operation dies, I stat again. I'm happy wi that. RAID 5 has write penalty performace hits (well known +update in place+), , RAID 6+ is lousy for huge objects but good for I.T. but ok if you lose two disks in a stripe (RANK).
They all have their flaws... and mirroring a RAID0 (RAID1/0) seems to be popular with storage vendors because they can see you more disk and thats proper business workflow depends on it.
However you can achieve this stuff if you change your workflow slightly.
Other than these the rest is tech specs and stuff under the cover.
So you what is right for you and your business.
I dont like spending money on nasty elcheapo FW800 LeCIE disk enclosures with the their junky components and their ilk having been done badly on several corrupted devices and lsing TB;s of content - this is why I invested in a high speed LTO4 ULtrium data tape archive solution.
sorry for long post..
w

Larger block size = faster DB?

hi guys,
(re Oracle 9.2.0.7)
it seems that a larger block_size makes the database perform operations faster? Is this correct? if so, why would anyone use 2k block sizes?
thanks

Hi Howard,
it's uncharted territory, especially at the higher blocksizes which seem to be less-well-tested than the smaller ones Yup, Oracle releases junkware all the time, untested poo . . .
You complain, file a bug report, and wait for years while NOTHING happens . . .
Tell me Howard, how incompetent does Oracle Corporation have to be not to test something as fundamental as blocksizes?
I've seen Oracle tech support in-action, it's like watching the Keystone Cops:
Oracle does not reveal the depth of their quality assurance testing, but many Oracle customers believe that Oracle does complete regression testing on major features of their software, such as blocksize. However, Oracle ACE Director Daniel Morgan, says that “The right size is 8K because that is the only size Oracle tests”, a serious allegation, given that the Oracle documentation, Oracle University and MetaLink all recommend non-standard blocksizes under special circumstances:
- Large blocks gives more data transfer per I/O call.
- Larger blocksizes provides less fragmentation (row chaining and row migration) of large objects (LOB, BLOB, CLOB)
- Indexes like big blocks because index height can be lower and more space exists within the index branch nodes.
- Moving indexes to a larger blocksize saves disk space. Oracle says "you will conserve about 4% of data storage (4GB on every 100GB) for every large index in your database by moving from a 2KB database block size to an 8KB database block size."
So, does Oracle really not do testing with non-standard blocksizes? Oracle ACE Director Morgan says that he was quoting Bryn Llewellyn of Oracle Corporation:
“Which brings us full circle to the statement Brynn made to me and that I have repeated several times in this thread. Oracle only tests 8K blocks.”
Wow.
Edited by: jkestely on Sep 1, 2008 2:52 PM

ORA-27046: file size is not a multiple of logical block size

Hi All,
Getting the below error while creating Control File after database restore. Permission and ownership of CONTROL.SQL file is 777 and ora<sid>:dba
ERROR -->
SQL> !pwd
/oracle/SID/sapreorg
SQL> @CONTROL.SQL
ORACLE instance started.
Total System Global Area 3539992576 bytes
Fixed Size                  2088096 bytes
Variable Size            1778385760 bytes
Database Buffers         1744830464 bytes
Redo Buffers               14688256 bytes
CREATE CONTROLFILE SET DATABASE "SID" RESETLOGS ARCHIVELOG
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01565: error in identifying file
'/oracle/SID/sapdata5/p11_19/p11.data19.dbf'
ORA-27046: file size is not a multiple of logical block size
Additional information: 1
Additional information: 1895833576
Additional information: 8192
Checked in target system init<SID>.ora and found the parameter db_block_size is 8192. Also checked in source system init<SID>.ora and found the parameter db_block_size is also 8192.
/oracle/SID/102_64/dbs$ grep -i block initSID.ora
Kindly look into the issue.
Regards,
Soumya

Please chk the following things
1.SPfile corruption :
Startup the DB in nomount using pfile (ie init<sid>.ora) create spfile from pfile;restart the instance in nomount state
Then create the control file from the script.
2. Check Ulimit of the target server , the filesize parameter for ulimit shud be unlimited.
3. Has the db_block_size parameter been changed in init file by any chance.
Regards
Kausik

Mac Pro RAID block size recommendations for working with audio in Logic Pro

I have recently ordered a Mac Pro and plan to do a RAID configuration across 3 HDD's
The RAID type i am going to do is a RAID 0 striped.
The computer is going to be used primarily for audio post production and working with 20+ 24-Bit audio files at any one time within a Logic project.
I want to know what is the best block size i should use when configuring the RAID.
I understand that using a higher block size is best for working with large files but do i need to do this in my case or will the default 32k block size be enough?
Thanks in advance

Use 64k. Things like databases like having 32k blocks because of all the small files. Audio files are pretty small even at 24-bit 192KHz. Go to 128k if all you are doing is streaming and no samples. But 20+ 24-bit is really not too large anyway considering most modern HDD's can stream 100MB/s off one spindle. You'll probably be fine regardless of the block size you choose. But most audio pro's choose 64k.

ORA-00349: failure obtaining block size for '+Z' in Oracle XE

Hello,
I am attempting to move the online redo log files to a new flash recovery area location created on network drive "Z" ( Oracle Database 10g Express Edition Release 10.2.0.1.0).
When I run @?/sqlplus/admin/movelogs; in SQL*Plus as a local sysdba, I get the following errors:
ERROR at line 1:
ORA-00349: failure obtaining block size for '+Z'
ORA-06512: at line 14
Please let me know how to go about resolving this issue.
Thank you.
See below for detail:
Connected.
SQL> @?/sqlplus/admin/movelogs;
SQL> Rem
SQL> Rem $Header: movelogs.sql 19-jan-2006.00:23:11 banand Exp $
SQL> Rem
SQL> Rem movelogs.sql
SQL> Rem
SQL> Rem Copyright (c) 2006, Oracle. All rights reserved.
SQL> Rem
SQL> Rem NAME
SQL> Rem movelogs.sql - move online logs to new Flash Recovery Area
SQL> Rem
SQL> Rem DESCRIPTION
SQL> Rem This script can be used to move online logs from old online
log
SQL> Rem location to Flash Recovery Area. It assumes that the database
SQL> Rem instance is started with new Flash Recovery Area location.
SQL> Rem
SQL> Rem NOTES
SQL> Rem For use to rename online logs after moving Flash Recovery
Area.
SQL> Rem The script can be executed using following command
SQL> Rem sqlplus '/ as sysdba' @movelogs.sql
SQL> Rem
SQL> Rem MODIFIED (MM/DD/YY)
SQL> Rem banand 01/19/06 - Created
SQL> Rem
SQL>
SQL> SET ECHO ON
SQL> SET FEEDBACK 1
SQL> SET NUMWIDTH 10
SQL> SET LINESIZE 80
SQL> SET TRIMSPOOL ON
SQL> SET TAB OFF
SQL> SET PAGESIZE 100
SQL> declare
2 cursor rlc is
3 select group# grp, thread# thr, bytes/1024 bytes_k
4 from v$log
5 order by 1;
6 stmt varchar2(2048);
7 swtstmt varchar2(1024) := 'alter system switch logfile';
8 ckpstmt varchar2(1024) := 'alter system checkpoint global';
9 begin
10 for rlcRec in rlc loop
11 stmt := 'alter database add logfile thread ' ||
12 rlcRec.thr || ' size ' ||
13 rlcRec.bytes_k || 'K';
14 execute immediate stmt;
15 begin
16 stmt := 'alter database drop logfile group ' || rlcRec.grp;
17 execute immediate stmt;
18 exception
19 when others then
20 execute immediate swtstmt;
21 execute immediate ckpstmt;
22 execute immediate stmt;
23 end;
24 execute immediate swtstmt;
25 end loop;
26 end;
27 /
declare
ERROR at line 1:
ORA-00349: failure obtaining block size for '+Z'
ORA-06512: at line 14
Can someone point me in the right direction as to what I may be doing wrong here - Thank you!

888442 wrote:
I am trying to drop and recreate ONLINE redo logs on my STANDB DATABASE (11.1.0.7)., but i am getting the below error.
On primary, we have done the changes., ie we added new logfile with bigger size and 3 members. When trying to do the same on Standby we are getting this error.
Our database is in Active DG Read only mode and the oracle version is 11.1.0.7.
I have deffered the log apply and cancelled the managed recovery, and dg is in manual mode.
SQL> alter database Add LOGFILE GROUP 4 ('+DT_DG1','+DT_DG2','+DT_DG3') SIZE 1024M;
alter database Add LOGFILE GROUP 4 ('+DT_DG1','+DT_DG2','+DT_DG3') SIZE 1024M
ERROR at line 1:
ORA-00349: failure obtaining block size for '+DT_DG1'First why you are dropping & recreating online redo log files on standby.
On standby only standby redo log files will be used. Not sure what you are trying to do.
here is example how to create online redo log files, Check that diskgroup is mounted and have sufficient space to create.
sys@ORCL> select member from v$logfile;
MEMBER
C:\ORACLE\ORADATA\ORCL\REDO03.LOG
C:\ORACLE\ORADATA\ORCL\REDO02.LOG
C:\ORACLE\ORADATA\ORCL\REDO01.LOG
sys@ORCL> alter database add logfile group 4 (
2     'C:\ORACLE\ORADATA\ORCL\redo_g01a.log',
3     'C:\ORACLE\ORADATA\ORCL\redo_g01b.log',
4     'C:\ORACLE\ORADATA\ORCL\redo_g01c.log') size 10m;
Database altered.
sys@ORCL> select member from v$logfile;
MEMBER
C:\ORACLE\ORADATA\ORCL\REDO03.LOG
C:\ORACLE\ORADATA\ORCL\REDO02.LOG
C:\ORACLE\ORADATA\ORCL\REDO01.LOG
C:\ORACLE\ORADATA\ORCL\REDO_G01A.LOG
C:\ORACLE\ORADATA\ORCL\REDO_G01B.LOG
C:\ORACLE\ORADATA\ORCL\REDO_G01C.LOG
6 rows selected.
sys@ORCL>
Your profile:-
888442
     Newbie
Handle:      888442
Status Level:      Newbie
Registered:      Sep 29, 2011
Total Posts:      12
Total Questions:      8 (7 unresolved)
Close the threads if answered, Keep the forum clean.

Tablespaces and block size in Data Warehouse

We are preparing to implement Data Warehouse on Oracle 11g R2 and currently I am trying to set up some storage strategy - unfortunately I have very little experience with that. The question is what are general advices in such considerations according table spaces and block size? I made some research and it is hard to find some clear answer, there are resources advising that block size is not important and can be left small (8 KB), others state that it is crucial and should be the biggest possible (64KB). The other thing is what part of data should be placed where? Many resources state that keeping indexes apart from its data is a myth and a bad practice as it may lead to decrease of performance, others say that although there is no performance benefit, index table spaces do not need to be backed up and thats why it should be split. The next idea is to have separate table spaces for big tables, small tables, tables accessed frequently and infrequently. How should I organize partitions in terms of table spaces? Is it a good idea to have "old" data (read only) partitions on separate table spaces?
Any help highly appreciated and thank you in advance.

Wojtus-J wrote:
We are preparing to implement Data Warehouse on Oracle 11g R2 and currently I am trying to set up some storage strategy - unfortunately I have very little experience with that. With little experience, the key feature is to avoid big mistakes - don't try to get too clever.
The question is what are general advices in such considerations according table spaces and block size? If you need to ask about block sizes, use the default (i.e. 8KB).
I made some research and it is hard to find some clear answer, But if you get contradictory advice from this forum, how would you decide which bits to follow ?
A couple of sensible guidelines when researching on the internet - look for material that is datestamped with recent dates (last couple of years), or references recent - or at least relevant - versions of Oracle. Give preference to material that explains WHY an idea might be relevant, give greater preference to material that DEMONSTRATES why an idea might be relevant. Check that any explanations and demonstrations are relevant to your planned setup.
The other thing is what part of data should be placed where? Many resources state that keeping indexes apart from its data is a myth and a bad practice as it may lead to decrease of performance, others say that although there is no performance benefit, index table spaces do not need to be backed up and thats why it should be split. The next idea is to have separate table spaces for big tables, small tables, tables accessed frequently and infrequently. How should I organize partitions in terms of table spaces? Is it a good idea to have "old" data (read only) partitions on separate table spaces?
It is often convenient, and sometimes very important, to separate data into different tablespaces based on some aspect of functionality. The performance thing was mooted (badly) in an era when discs were small and (disk) partitions were hard; but all your other examples of why to split are potentially valid for administrative. Big/Small, table/index, old/new, read-only/read-write, fact/dimension etc.
For data warehouses a fairly common practice is to identify some sort of aging pattern for the data, and try to pick a boundary that allows you to partition data so that a large fraction of the data can eventually be made read-only: using tablespaces to mark time-boundaries can be a great convenience - note that the tablespace boundary need not match the partition boudary - e.g. daily partitions in a monthly tablespace. If you take this type of approach, you might have a "working" tablespace for recent data, and then copy the older data to "time-specific" tablespace, packing it and making it readonly as you do so.
Tablespaces are (broadly speaking) about strategy, not performance. (Temporary tablespaces / tablespace groups are probably the exception to this thought.)
Regards
Jonathan Lewis

Raid storage usage and block size

We have two XServe RAID units Raid 5 and we are adding a new 16 bay ACNC raid with 16 1.5TB drives in Raid 6 + Hot Spare. I initialized the Raid 6 with 128K block size. The total data moving from the older raid volumes is around 5.7TB, but on the new Raid it is taking around 7.4TB of space. Is this due to the 128K block size? This is a prepress server so most of the files are quite large, but there may be lots of small files as well.

Hi
RAID 0 does indeed offer best performance, however if any one drive of the striped set fails you will lose all your data. If you have not considered a backup strategy now would be the time to do so. For redundancy RAID 1 Mirror might be a better option as this will offer a safety net in case of a single drive failure. A RAID is not a backup and you should always consider a workable backup strategy.
Purchase another 2x1TB drives and you could consider a RAID 10? Two Stripes mirrored.
Not all your files will be large ones as I'm guessing you'll be using this workstation for the usual mundane matters such as email etc? Selecting a larger block size with small file sizes usually decreases performance. You have to consider all applications and file sizes, in which case the best block size would be 32k.
My 2p
Tony

Can't change default block size in dbca

10.1.0.3
solaris
I am using the dbca to create a database. When I go to the sizing screen and try to change the default block size this option is always greyed out at 8k.
does anyone know why? this happens even when i pick a data warehouse template.

There is a reason Oracle uses 8K as the default database block size for their warehouse template. Changing the default block size to a larger size generally does not result in better performance when both databases are allocated the exact same SGA memory allocations.
HTH -- Mark D Powell --

Change block size for several log-files simultaneously?

Hi,
I'm using SignalExpress to record and analyze data.
Sometimes I want to analyze the recorded data both for a short period of time and for longer time.
(Imagine creating an average of every second first and then an average of every 10 seconds)
Then I need to change all the log-files, and also the specific parts of the log-file. See attachment.
I have sometimes up to 1000 log-files containing signals from 4 different modules, that makes 4000 adjustments to change from block size 10000 to block size 1000.
Is there any way to adjust all the log-files block size at once?
Many thanks!
Anders Hansson
Engineer
Attachments:
NI.JPG ‏95 KB

Hi,
Is't anyone else interested in a solution for this operation?
I reported this to the NI-feedback service and they adviced me to report/request advice here to get a quicker reply.
So...
Best regards
Ingenjör Hansson

Mirrored RAID: MediaKit reports block size error

I am trying to create a 2nd set up backup drives for my photos. I have two new iomega 2TB drives, which look essentially identical to drives I'm currently using as my primary backups as a mirrored RAID set.
I can start the process with freshly erased and reformatted drives (with the default mac format, extended, journaled, unencrypted, not case-sensitive). And after a minute or three, I see
"MediaKit reports block size error, usually caused by not being a multiple of 512."
The RAID options are Mirrored RAID, Mac extended journaled, and options settings are default.
I see several series of posts with complaints about encrypting RAIDs and disk block sizes, but not unencrypted errors. I actually started out trying to do this with the 2006 MBP running 10.6.8 and got a different error: "POSIX reports: the operation couldn't be completed. Operation not permitted." I wasn't sure whether the 2TB RAID I already have was set up iwth the older or newer computer--it was definitely before I put Lion on this one--so I tried this one and now have a different error.
Any idea what the problem might be?

Update: I spent some time on the phone with an Apple support RAID expert, and couldn't figure out what the error was; we couldn't bypass it by playing with partitions on the drives, or any of another couple of manuevers that I've already forgotten. He noted that his own searches were showing a lot of mentions of similar problems but only with Iomega drives, and he was finding the same links I found earlier about problems creating encrypted drives. Now trying to decide if it's worth throwing more good money after bad for a call with Iomega support, and waiting to see if the iomega forum is at all helpful.

RAID block size for final cut pro x

Just got one of the new late 2012 27" iMacs and a 6 TB LaCie Thunderbolt drive. Can finally edit the video I took last spring. I'll be using Final Cut Pro X, and doing a lot of multicam stuff with 4 or 5 views and a separate audio track. The LaCie came formatted as a mirrored RAID. I'm going to change that to 0 (Striped RAID set), but am wondering what block size to set. The default is 32k, but I have read that this ought to be increased to the max (256k) for video editing. I have also read it should NOT be increased. And the posts I have read have all been at least 3 years old. So let me ask you all--what block size would you recommend for my situation?
Thanks in advance!

Hi Eddie...
This depends on what kind of source footage you are editing....
For compressed Video, Audio and Uncompressed audio 128k
I have only had BAD results with 256k. 64 is also weird. Whereas 32 is fine.
All my RAIDs have 128k for audio/video editing
you can go further if you editing Image Sequences.. but according to my own findings and I have been dealing with raid since years.... 128k does the job the best.
Rule of thumb.... The smaller the file sizes you are putting the RAID the smaller the block size. And vice versa.
I.e. You would cripple the raid performance if storing a database on it, having a block size of 256. In case of servers and OS 32k would be a good choice, perhaps even 16k if supported.

OSD-04001: invalid logical block size (OS 2800189884)

My Windows 2003 crashed which was running Oracle XE.
I installed Oracle XE on Windows XP on another machine.
I coped my D:\oracle\XE10g\oradata folder of Win2003 to the same location in WinXP machine.
When I start the database in WinXP using SQLPLUS i get the following message
SQL> startup
ORACLE instance started.
Total System Global Area 146800640 bytes
Fixed Size 1286220 bytes
Variable Size 62918580 bytes
Database Buffers 79691776 bytes
Redo Buffers 2904064 bytes
ORA-00205: error in identifying control file, check alert log for more info
I my D:\oracle\XE10g\app\oracle\admin\XE\bdump\alert_xe I found following errors
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 4 shared server(s) ...
Oracle Data Guard is not available in this edition of Oracle.
Wed Apr 25 18:38:36 2007
ALTER DATABASE MOUNT
Wed Apr 25 18:38:36 2007
ORA-00202: control file: 'D:\ORACLE\XE10G\ORADATA\XE\CONTROL.DBF'
ORA-27047: unable to read the header block of file
OSD-04001: invalid logical block size (OS 2800189884)
Wed Apr 25 18:38:36 2007
ORA-205 signalled during: ALTER DATABASE MOUNT...
ORA-00202: control file: 'D:\ORACLE\XE10G\ORADATA\XE\CONTROL.DBF'
ORA-27047: unable to read the header block of file
OSD-04001: invalid logical block size (OS 2800189884)
Please help.
Regards,
Zulqarnain

Hi Zulqarnain,
Error OSD-04001 is Windows NT specific Oracle message. It means that the logical block size is not a multiple of 512 bytes, or it is too large.
So what you can do? Well you should try to change the value of DB_BLOCK_SIZE in the initialization parameter file.
Regards

ORA-00349: failure obtaining block size

I am trying to drop and recreate ONLINE redo logs on my STANDB DATABASE (11.1.0.7)., but i am getting the below error.
On primary, we have done the changes., ie we added new logfile with bigger size and 3 members. When trying to do the same on Standby we are getting this error.
Our database is in Active DG Read only mode and the oracle version is 11.1.0.7.
I have deffered the log apply and cancelled the managed recovery, and dg is in manual mode.
SQL> alter database Add LOGFILE GROUP 1 ('+DT_DG1','+DT_DG2','+DT_DG3') SIZE 1024M;
alter database Add LOGFILE GROUP 1 ('+DT_DG1','+DT_DG2','+DT_DG3') SIZE 1024M
ERROR at line 1:
ORA-00349: failure obtaining block size for '+DT_DG1'

888442 wrote:
I am trying to drop and recreate ONLINE redo logs on my STANDB DATABASE (11.1.0.7)., but i am getting the below error.
On primary, we have done the changes., ie we added new logfile with bigger size and 3 members. When trying to do the same on Standby we are getting this error.
Our database is in Active DG Read only mode and the oracle version is 11.1.0.7.
I have deffered the log apply and cancelled the managed recovery, and dg is in manual mode.
SQL> alter database Add LOGFILE GROUP 4 ('+DT_DG1','+DT_DG2','+DT_DG3') SIZE 1024M;
alter database Add LOGFILE GROUP 4 ('+DT_DG1','+DT_DG2','+DT_DG3') SIZE 1024M
ERROR at line 1:
ORA-00349: failure obtaining block size for '+DT_DG1'First why you are dropping & recreating online redo log files on standby.
On standby only standby redo log files will be used. Not sure what you are trying to do.
here is example how to create online redo log files, Check that diskgroup is mounted and have sufficient space to create.
sys@ORCL> select member from v$logfile;
MEMBER
C:\ORACLE\ORADATA\ORCL\REDO03.LOG
C:\ORACLE\ORADATA\ORCL\REDO02.LOG
C:\ORACLE\ORADATA\ORCL\REDO01.LOG
sys@ORCL> alter database add logfile group 4 (
2     'C:\ORACLE\ORADATA\ORCL\redo_g01a.log',
3     'C:\ORACLE\ORADATA\ORCL\redo_g01b.log',
4     'C:\ORACLE\ORADATA\ORCL\redo_g01c.log') size 10m;
Database altered.
sys@ORCL> select member from v$logfile;
MEMBER
C:\ORACLE\ORADATA\ORCL\REDO03.LOG
C:\ORACLE\ORADATA\ORCL\REDO02.LOG
C:\ORACLE\ORADATA\ORCL\REDO01.LOG
C:\ORACLE\ORADATA\ORCL\REDO_G01A.LOG
C:\ORACLE\ORADATA\ORCL\REDO_G01B.LOG
C:\ORACLE\ORADATA\ORCL\REDO_G01C.LOG
6 rows selected.
sys@ORCL>
Your profile:-
888442
     Newbie
Handle:      888442
Status Level:      Newbie
Registered:      Sep 29, 2011
Total Posts:      12
Total Questions:      8 (7 unresolved)
Close the threads if answered, Keep the forum clean.

Data block size

I have just started reading the concepts and I got to know that Oracle database data is stored in data blocks. The standard block size is specified by
DB_BLOCK_SIZE init parameter. Additionally we can specify upto 5 other block sizes using DB_nK_CACHE_SIZE parameter.
Let us say I define in the init.ora
DB_BLOCK_SIZE = 8K
DB_CACHE_SIZE = 4G
DB_4K_CACHE_SIZE=1G
DB_16K_CACHE_SIZE=1G
Questions:
a) Does this mean I can create tablespaces with 8K, 4K and 16K block sizes only?
b) whenever I query data from these tablespaces, it will go and sit in these respective cache sizes?
Thanks in advance.
Neel

yes, it will give error message if you create tablespace with non standard block size without specify the db_nk_cache_size parameter in the init parameter file .
Use the BLOCKSIZE clause of the CREATE TABLESPACE statement to create a tablespace with a block size different from the database standard block size. In order for the BLOCKSIZE clause to succeed, you must have already set the DB_CACHE_SIZE and at least one DB_nK_CACHE_SIZE initialization parameter. Further, and the integer you specify in the BLOCKSIZE clause must correspond with the setting of one DB_nK_CACHE_SIZE parameter setting. Although redundant, specifying a BLOCKSIZE equal to the standard block size, as specified by the DB_BLOCK_SIZE initialization parameter, is allowed.
The following statement creates tablespace lmtbsb, but specifies a block size that differs from the standard database block size (as specified by the DB_BLOCK_SIZE initialization parameter):
CREATE TABLESPACE lmtbsb DATAFILE '/u02/oracle/data/lmtbsb01.dbf' SIZE 50M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K
BLOCKSIZE 8K;
reference:-http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/tspaces003.htm

DPM transfer block size

Similar Messages

Maybe you are looking for