toasters

toasters@lists.teaparty.net

3 participants
13534 discussions

RE: SMSQL help!!
by Ken Williams 02 Dec '08

02 Dec '08

I just spent some time switching to the 32bit version, I received the same results. -----Original Message----- From: Chaim Rieger [mailto:riegersteve@gmail.com] Sent: Tuesday, December 02, 2008 1:13 PM To: Ken Williams Cc: toasters(a)mathworks.com Subject: Re: SMSQL help!! -SMSQL 2.1.1 (previously) and 2.1.2 (currently) you have to install the 32 bit version of SM (if my recollection serves right) we ran into this issue as well Ken Williams wrote: > I've been working with support for several days now on this issue and we > are all stumped. > > Quick background on the environment: > -Clustered FAS3070 > -Fiber channel LUNs > - OnTap 7.2.5.1 > -Windows Server 2003 R2 64bit clustered configuration > -MS SQL 2005 > -1 LUN per filer volume, using mount point vs drive letters for > the mounts. > -SMSQL 2.1.1 (previously) and 2.1.2 (currently) > > This clustered environment is for Sharepoint and also has SMMOSS member > agents. > > This problem has existed since configuration. > > We're in the process of migrating data to a new SQL cluster and we're > coming across a issue with the DBCC verification. > > Collecting verification information... > Getting database backup information from SnapInfo file... > Initializing SnapManager server on remote machine [SNPSPDB01]... > Mounting Snapshot [sqlsnap__prdspdb01_12-02-2008_12.21.38] for Virtual > Disk F:\shpntprod_db\ of Computer PRDSPDB01 > This Snapshot is mounted as the drive [Z:]. > Mount Snapshot succeeded. > Mounting Snapshot [sqlsnap__prdspdb01_12-02-2008_12.21.38] for Virtual > Disk F:\shpntprod_log\ of Computer PRDSPDB01 > This Snapshot is mounted as the drive [Y:]. > Mount Snapshot succeeded. > */Cannot find the data file in the mounted drive:/* > */f:\shpntprod_db\PRD_Hydro_Content_01.mdf/*// > Dismounting Virtual Disk Z of SnapShot > [sqlsnap__prdspdb01_12-02-2008_12.21.38]... > Dismount Snapshot succeeded. > Dismounting Virtual Disk Y of SnapShot > [sqlsnap__prdspdb01_12-02-2008_12.21.38]... > Dismount Snapshot succeeded. > Unable to locate the database data file on the mounted disk drive. > > Database verification information was not updated. > There is an error during database verification. > > > Any ideas why the verification would fail? It looks to me like its > trying to find a data file mounted on the f:\ drive instead of the Y:\ > or Z:\ drive.. Could this be some type of SQL permission issue? I'm at a > total loss. > > Here is the kicker: When I installed SMSQL5.0 the problem went away, but > SMMOSS (Snapmanager for Share point) doesn't work with SMSQL5.0, it > requires 2.1.1/.2.1.2 > > > __________________________________________________________ > *****Ken Williams* > ///Storage Administrator, Business Technology Operations/ > ***Sacramento Municipal Utility District* > E-Mail:_ __kwillia(a)smud.org_ > Phone: (916) 732-6744 > Cell: (916) 240-4213 > -- -- Chaim Rieger www.jravel.com

1 0

Re: SD 6.01 / W2K8 x64 / iSCSI and NLB Cluster
by Raj Patel 02 Dec '08

02 Dec '08

Cheers Tom We've done some more troubleshooting - * if I do a clean w2k8 server install with two nics (one data and the other iscsi) - SD 6.01 installs and works fine - the initiator even prompts to open the FW ports on the server This made me think it was either something fishy with my previous install or something funny with the cluster (which is purely failover - no shared storage). * if we evict one of the cluster members (there are two mailbox servers) the SD 6.01 RPC problem goes away immediately So now I'm running up some test VM's to replicate the setup and run up SD first and then put the cluster on afterwards. What I'm wondering now is what part of the SD / SAN interaction is making the RPC call - presumably over the clustered address ? Is there any way to tie it to a particular IP or NIC ? We'll run another test with a couple of vm's, creating the luns and then creating the cluster - see at what point the RPC error occurs. Cheers, Raj. On Tue, Dec 2, 2008 at 10:04 PM, De Wit Tom (Consultant) <tom.de.wit(a)consultant.volvo.com> wrote: > I know of two things that can cause such errors: > > - Fill in the "Preferred filer IP addresses". I don't have SD 6.x, on 4.2.1 it was located in MMC under Storage/Snapdrive/Disks, rightclick Disks, select properties. Then fill in the filer DNS/Netbios name and the corresponding IP address and restart Snapdrive services > > - Make sure the Snapdrive services is started with a domain user that has both local admin rights on the local server and admin rights on the Netapp filer. > > Grtz, > Tom >

1 0

SMSQL help!!
by Ken Williams 02 Dec '08

02 Dec '08

I've been working with support for several days now on this issue and we are all stumped. Quick background on the environment: -Clustered FAS3070 -Fiber channel LUNs - OnTap 7.2.5.1 -Windows Server 2003 R2 64bit clustered configuration -MS SQL 2005 -1 LUN per filer volume, using mount point vs drive letters for the mounts. -SMSQL 2.1.1 (previously) and 2.1.2 (currently) This clustered environment is for Sharepoint and also has SMMOSS member agents. This problem has existed since configuration. We're in the process of migrating data to a new SQL cluster and we're coming across a issue with the DBCC verification. Collecting verification information... Getting database backup information from SnapInfo file... Initializing SnapManager server on remote machine [SNPSPDB01]... Mounting Snapshot [sqlsnap__prdspdb01_12-02-2008_12.21.38] for Virtual Disk F:\shpntprod_db\ of Computer PRDSPDB01 This Snapshot is mounted as the drive [Z:]. Mount Snapshot succeeded. Mounting Snapshot [sqlsnap__prdspdb01_12-02-2008_12.21.38] for Virtual Disk F:\shpntprod_log\ of Computer PRDSPDB01 This Snapshot is mounted as the drive [Y:]. Mount Snapshot succeeded. Cannot find the data file in the mounted drive: f:\shpntprod_db\PRD_Hydro_Content_01.mdf Dismounting Virtual Disk Z of SnapShot [sqlsnap__prdspdb01_12-02-2008_12.21.38]... Dismount Snapshot succeeded. Dismounting Virtual Disk Y of SnapShot [sqlsnap__prdspdb01_12-02-2008_12.21.38]... Dismount Snapshot succeeded. Unable to locate the database data file on the mounted disk drive. Database verification information was not updated. There is an error during database verification. Any ideas why the verification would fail? It looks to me like its trying to find a data file mounted on the f:\ drive instead of the Y:\ or Z:\ drive.. Could this be some type of SQL permission issue? I'm at a total loss. Here is the kicker: When I installed SMSQL5.0 the problem went away, but SMMOSS (Snapmanager for Share point) doesn't work with SMSQL5.0, it requires 2.1.1/.2.1.2 __________________________________________________________ Ken Williams Storage Administrator, Business Technology Operations Sacramento Municipal Utility District E-Mail: kwillia(a)smud.org Phone: (916) 732-6744 Cell: (916) 240-4213

1 0

moving data off of a spare disk.
by Ellis, Brent 02 Dec '08

02 Dec '08

I have a situation where a disk failed and the rebuild started on the spare from another shelf of disks. The spare was larger than the original failed disk and I need that spare to be available for the aggregate using the larger disks. How do I force the data off that disk and onto one of the other spare disks? Do I just wait for the rebuild to finish and then fail it? Brent Boston University

3 3

Crazy disk swap thought
by Peta Spies 01 Dec '08

01 Dec '08

Hi all, We have a ton of shelves with 320gb sata in them. We'd like to replace them with 1tb satas, but we have no power to power new shelves, or much space for them for that matter. I know that if I swap out one 320gb disk with a 1tb one, the netapp will only use 320gb of the 1tb disk. But if I did all 14, one at a time so it syncs, what happens after I change the 14th disk? Will the netapp still only use 320gb per disk, or will it realise it has a whole 1tb to play with? Peta

7 6

7.2.x snapmirror to 7.3 and back again
by Roscoe P Coltraine 01 Dec '08

01 Dec '08

i have a filer on 7.2.4 with a very large volume size of 12164g. i need to do some loop reorginzation and want to snapmirror it off to a newer filer running 7.3 and then delete it to free up space for some other volume migrations and shelf swaps. when all is said and done i want to put this volume back. so the question is will i be able to snapmirror it back from 7.3 to 7.2.x?

4 4

SD 6.01 / W2K8 x64 / iSCSI and NLB Cluster
by Raj Patel 28 Nov '08

28 Nov '08

Hi all, A few queries about the above config - We are setting up a new E2k7 system with 2 front end CAS servers with NLB and 2 back end Mailbox servers in NLB config and doing CCR between them (no shared storage). I was able to install SnapDrive 6.01 and create four LUN's (non shared dedicated) on each Mailbox server on two seperate SAN's for the mail stores & logs. No problem. However as soon I rebooted and went to check the LUN's (which stayed connected) and create a new one I got a couple of errors (different on each system) - RPC server unavailable - Security package related error Oddly I can expand existing LUN's OK via SD - so some functionality exists - just can't create a new LUN within SD. I have had a suggestion to make sure the Windows Quorum Witness Disk should also be on the SAN - following Microsoft best practive I've created a small Quorum Witness Disk and share on a CAS server. Thats fine - still doesn't fix the RPC error (I can ping and access the admin share on the SAN from each mailbox server). The most annoying thing is that none of these issues has cropped up with W2K3 and SD 4.2.1 - I'm following the same fundamental setup steps. Given I'm not using shared storage clustering just CCR and NLB I want to discover the root of the SD errors - is it SD trying to be clever and insisting that for a Windows cluster you really need shared disks registered with the cluster administrator regardless of wether they're shared or not ? - just some weirdness with W2K8 and SD 6.01 ? - are there any gotchas with W2K8 and SD 6.01 that I need to be aware of ? I just noticed theres a DCOM exception for the W2K8 firewall on NOW - how come SD doesn't set this stuff up at install time ? I want to eliminate the clustering ASAP issue because until I nail the problem the Exchange guys can't really proceed with the rest of the install. Particularly if I need to keep messing around with breaking and re-establishing the cluster to sort out an RPC error. Thanks in advance, Raj.

1 0

Re: Downgrading Data ONTAP?
by Simon Vallet 28 Nov '08

28 Nov '08

Hi, On Tue, 25 Nov 2008 18:37:56 +0100 "Patrick van Helden" <pvh(a)databasement.eu> wrote: > I have reverted Ontap on several occasions, and yes before the revert > you will have to delete all the snapshots that were made with the new > Ontap version. Any snapshots made with the old version of ontap can > remain on the system. Confirmed. We downgraded yesterday, and it went quite well; the procedure from NetApp did indeed hint at deleting previous snapshots before downgrading. This cluster seems in good shape now. Let's just hope it'll stay that way ;-) Simon -- Simon Vallet Ingénieur systèmes, réseaux, sécurité CEA DSV/IG/GEN - Genoscope Tél.: +33 1 60 87 36 06 Mél.: svallet(a)genoscope.cns.fr

1 0

Re: vfiler migrate - qtree level mounts
by Fox, Adam 27 Nov '08

27 Nov '08

I can't see how this would be the case as long as you're SnapMirror relationships are volume-based, which vfiler migrate should do by default. But if you are migrating at the qtree level, clients would have to remount. -- Adam Fox ------------------------ Typed with my thumbs on a very small keyboard. ----- Original Message ----- From: Buerger, Andreas <andreas.buerger(a)wincor-nixdorf.com> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Thu Nov 27 11:14:08 2008 Subject: vfiler migrate - qtree level mounts Hi, I want to perform a vfiler migrate in a production evironment this weekend, and regarding that I had a deeper look at the documentation at NOW. I did the migrate procedure some times before but always with non production data, and every time the migration went smooth without any client interuption (just nfs access). But when I had a deeper look at the documentation I was a little worried about the following chapter, how does a vfiler migration affect clients: http://now.netapp.com/NOW/knowledge/docs/ontap/rel73_vs/html/ontap/vfile r/provisioning/concept/c_oc_prov_vfiler-dr-how-migrating-affects-clients .html#c_oc_prov_vfiler-dr-how-migrating-affects-clients (same at the 7.2.5 documenation) # NFS volume-level mounts move transparently. # NFS qtree-level mounts need to be remounted. I tested that yesterday and and I can't reproduce that qtree level mounts need to be remounted after a vfiler migrate. Nearly every mount in our environment is based on the qtree level, so we would have a big problem if that's true. When I performed vfiler migrations in the past I never had any errors, it was just like a filer reboot or takeover, and I'm pretty sure that I had a lot qtree level mounts on the clients that were affected. Can anybody explain, why a qtree level mount needs be remounted like the documentation says? And whats the difference for the client if it mounts a complete volume like filer:/vol/volume or a qtree like filer:/vol/volume/qtree? May be someone can put me on the right way. Cheers Andreas -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

vfiler migrate - qtree level mounts
by Buerger, Andreas 27 Nov '08

27 Nov '08

Hi, I want to perform a vfiler migrate in a production evironment this weekend, and regarding that I had a deeper look at the documentation at NOW. I did the migrate procedure some times before but always with non production data, and every time the migration went smooth without any client interuption (just nfs access). But when I had a deeper look at the documentation I was a little worried about the following chapter, how does a vfiler migration affect clients: http://now.netapp.com/NOW/knowledge/docs/ontap/rel73_vs/html/ontap/vfile r/provisioning/concept/c_oc_prov_vfiler-dr-how-migrating-affects-clients .html#c_oc_prov_vfiler-dr-how-migrating-affects-clients (same at the 7.2.5 documenation) # NFS volume-level mounts move transparently. # NFS qtree-level mounts need to be remounted. I tested that yesterday and and I can't reproduce that qtree level mounts need to be remounted after a vfiler migrate. Nearly every mount in our environment is based on the qtree level, so we would have a big problem if that's true. When I performed vfiler migrations in the past I never had any errors, it was just like a filer reboot or takeover, and I'm pretty sure that I had a lot qtree level mounts on the clients that were affected. Can anybody explain, why a qtree level mount needs be remounted like the documentation says? And whats the difference for the client if it mounts a complete volume like filer:/vol/volume or a qtree like filer:/vol/volume/qtree? May be someone can put me on the right way. Cheers Andreas -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Gesch�ftsf�hrer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. J�rgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enth�lt vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt�mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters