Là nói chuyện Oracle DBA mới của tôi


15

Khi chúng tôi thiết lập các LUN FC cho các hộp MSSQL của mình, chúng tôi hiếm khi phải trình bày chúng với hơn 8 LUN khác nhau (Quorum, MSDTC, TempDB, Dữ liệu, Nhật ký, Sao lưu và một vài thứ khác).

Chúng tôi có một DBA mới của Oracle và anh ấy đã đưa cho tôi một danh sách các LUN anh ấy muốn cho máy chủ mới đầu tiên của mình - có 38 người trong số họ! và đây là một hộp DB thực sự cơ bản, chỉ có một DB duy nhất. Chúng đều là các LUN khá nhỏ (100 GB) và chúng rõ ràng kết hợp với nhau bằng cách sử dụng ASM theo cách thức LVM.

Đây có phải là cách tốt nhất để làm việc này không, tôi thực sự không phải là chuyên gia của Oracle nhưng có vẻ như quá sức với tôi, suy nghĩ và kinh nghiệm của bạn về vấn đề này là gì?


1
38 LUN cho một DB ... cái gì?!?!
Zypher

Câu trả lời:


19

Tôi là một DBA của Oracle. DBA mới của bạn hoạt động giống như rất nhiều DBA của Oracle và về kỹ thuật.

  1. KHÔNG CÓ lời tiên tri KHÔNG cần 38 LUN. Tôi đã phát tán các tệp dữ liệu trên một số lượng lớn lun nhưng chúng nằm trên các hệ thống RẤT hoạt động và RẤT lớn. LUN không cần ánh xạ tới các nhóm RAID mới phải không? Vì vậy, có các tập tin trên các lun riêng biệt không cần thiết phải lan truyền bất cứ điều gì (tôi không phải là một chuyên gia về điều này).

  2. Tất cả các loại phân loại tệp này sẽ làm là làm cho DBA làm việc nhiều hơn nữa. Điều này làm tăng tầm quan trọng của anh ấy đối với đội. Rất nhiều DBA của Oracle cố gắng làm cho bản thân dường như quan trọng hơn và vượt qua mọi thứ kỹ sư TẤT CẢ THỜI GIAN.

  3. Thu thập dữ liệu ra các nhóm / lun đột kích differnet không phải là lời tiên tri cụ thể. Nó dựa trên việc sử dụng. Để phân tán chính xác các tệp, DBA của bạn cần phải hiểu ứng dụng để biết những gì đang được truy cập rất nhiều (btw, tách các chỉ mục khỏi dữ liệu KHÔNG cải thiện hiệu suất vì truy cập là nối tiếp ...). Anh ấy có biết ứng dụng không? Anh ta đã nhìn vào cơ sở dữ liệu để xem những đối tượng nào đang được truy cập rất nhiều? Những gì cần phải được trải ra? Những gì không viết và đọc số lượng lớn và cần phải được cô lập.

Điều này nghe có vẻ như một cơ sở dữ liệu kích thước nhỏ / trung bình. Mức độ hoạt động là gì? Anh ta có lẽ không biết.

Nói chung trên các cơ sở dữ liệu nhỏ hơn, bạn không cần phải làm nhiều ở cấp hệ thống tệp để cải thiện hiệu suất. 95% là SQL và các nhà phát triển chạy quá nhiều câu lệnh sql trong các vòng lặp.

chỉnh sửa ( năm sau !):

Tôi đã dành thời gian nói chuyện với các kỹ sư SAN và đã nâng cao kiến ​​thức về SAN và LUN một chút kể từ khi đăng bài này. Trước hết, một LUN là "hợp lý". Không cần bản đồ để phân tách các nhóm RAID, đĩa, v.v ... Đó là thiết lập của kỹ sư SAN và sẽ không hiển thị cho DBA. Có rất nhiều điều để tách IO trong SAN mà hầu hết mọi người đều nhận ra.

Tôi đang làm việc trên một hệ thống rất lớn có mức độ hoạt động rất cao. Chúng tôi có hàng trăm LUN, Nhóm RAID, v.v ... chúng tôi phát tán các tệp ở khắp mọi nơi. Chúng tôi làm việc với các kỹ sư SAN để định cấu hình LUN để đảm bảo chúng được lan truyền đến các phần khác nhau của SAN. Chúng tôi thực sự KHÔNG có tầm nhìn về cách các LUN được ánh xạ từ cấp độ HĐH. Một hệ thống tệp mới không có nghĩa là chúng tôi đã ánh xạ dữ liệu đến một vị trí mới trên SAN.

Theo như bài viết của HP về tước ASM. Điều này là hoàn toàn vô nghĩa khi làm việc với SAN. Các dải, phản chiếu, RAID, vv ... đều được thực hiện dưới bề mặt. Bạn sẽ không nhìn thấy nó ở cấp ứng dụng hoặc cơ sở dữ liệu. Việc định cấu hình Oracle ASM để 'bóc tách' là vô nghĩa trong SAN, bởi vì bạn sẽ bỏ qua các khối hợp lý có thể sử dụng cấu hình RAID 5 (phần lớn do chi phí kiểm soát. SAN là khoản đầu tư hàng triệu đô la). Bạn sẽ chỉ thấy hệ thống tập tin. Những cái đó không nhất thiết phải ánh xạ tới các đĩa khác nhau hoặc các vị trí khác nhau trong SAN.

IBM rõ ràng có một tính năng mới cho phép SAN quyết định ghi vào đĩa dựa trên hoạt động. Quan điểm của tôi ở đây là những người tối ưu hóa SAN là các chuyên gia. Bạn cần phải làm việc với họ. Một DBA hoặc nhà phát triển ứng dụng sẽ không có khả năng hiển thị để xem liệu có bất cứ điều gì đang được trải ra không.

Từ những gì tôi đã thấy hầu hết các cửa hàng không có các kỹ sư SAN rất giỏi. Nó có xu hướng là một công việc cho những người cấp cơ sở. Hầu hết những người tốt có xu hướng được tư vấn. Vì vậy, rất nhiều thời gian bạn chỉ sử dụng thiết lập mặc định của nhà sản xuất. Để nhắc lại việc thêm nhiều LUN có thể sẽ không lan truyền bất kỳ dữ liệu nào, trừ khi bạn có một kỹ sư SAN định cấu hình nó cho bạn dưới bề mặt. Trên hết, bạn có thể có 1 LUN và có nó trải ra cho bạn. Trừ khi bạn có một kỹ sư SAN giỏi, tất cả những thứ này là vô nghĩa. Rõ ràng với tôi rằng DBA trong câu hỏi không biết đủ về SAN để thậm chí biết anh ta không biết gì.

99,9% cấu hình tiêu chuẩn thời gian là tốt. Trừ khi bạn có một nút cổ chai IO cụ thể, điều này là không cần thiết. Nếu bạn làm như vậy, thì bạn cần phải làm việc với kỹ sư SA và SAN để xác định vấn đề là gì. Rất nhiều thời gian nó KHÔNG CÓ gì để làm với bố cục của SAN. Một lần nữa, các DBA và nhà phát triển sẽ không có quyền truy cập để xem những gì đang diễn ra bên dưới chứ đừng nói đến kiến ​​thức để tìm hiểu điều này. SAN rất phức tạp.


Với tất cả sự tôn trọng, chỉ cần một vài điểm chú ý: - 1. "SAN rất phức tạp" - Cơ sở dữ liệu của Oracle cũng vậy. Thậm chí là một trong những sản phẩm có giá cao nhất trong bất kỳ cơ sở hạ tầng CNTT hoặc hệ thống CNTT. 2. "Dải / trải / ect" - Đồng ý. Các DBA không cần biết những gì đang diễn ra bên dưới miễn là họ không bao giờ phải đối mặt với các vấn đề với I / O - nhưng thật không may, nó luôn luôn bị tắc nghẽn IO cho bất kỳ vấn đề nào liên quan đến hiệu suất. 3. Một lần nữa các DBA khác nhau - DBA Infra / Core so với DBA ứng dụng. Infra DBA được giao nhiệm vụ với các hoạt động liên quan đến DB làm việc với HĐH & đĩa (SAN) - vì vậy anh ta phải có kiến ​​thức tốt về những gì đang diễn ra. 4. Tất cả những điều trên

5

Bạn có thể cố gắng đánh vào đầu anh ấy bằng NÀY , mô tả phương pháp CÙNG (Sọc và Gương mọi thứ), rất đơn giản.


1
Tôi nghĩ đó là những gì anh ta đang cố gắng thực hiện - không nhận ra rằng mảng của chúng tôi là một con quái vật đã khó chịu với RAID10.
Chopper3

4

Tôi không có câu trả lời trực tiếp vì chúng tôi sử dụng MSSQL và mySQL. Nhưng bất cứ khi nào DBA của tôi yêu cầu thứ gì đó nghe có vẻ điên rồ ... như thế. Tôi yêu cầu anh ta ghi lại lý do tại sao mỗi phần được yêu cầu. Điều này phục vụ hai mục đích rất nhiều lần họ đột nhiên thay đổi ý định của mình sang một điều gì đó lành mạnh hơn và hai cho phép tôi thấy quá trình suy nghĩ của họ để tôi có thể áp dụng một số logic hệ thống cho những gì họ muốn và đưa ra một giải pháp thay thế không phù hợp . Vì vậy, trong trường hợp này tôi sẽ yêu cầu một tài liệu chứng minh sự cần thiết của mỗi 38 LUN


Cảm ơn phản hồi, tôi đã yêu cầu điều này nhưng anh ấy chưa trả lời, nghĩ rằng tôi sẽ kiểm tra với bạn những người tốt trước;)
Chopper3

2

Có những nghiên cứu cho thấy việc lột xác trong ASM và ở cấp độ phần cứng có thể là một lợi thế cho hiệu suất. Bảng trắng HP-Oracle Những mức tăng hiệu suất này hầu hết được nhìn thấy trong các tình huống đồng thời cao mà nó không giống như bạn mong đợi. Nhưng có thể là những gì DBA của bạn được sử dụng để.


Trên thực tế điều này sẽ rất đồng thời, chỉ là một DB đơn giản - cảm ơn.
Chopper3

1

Tôi biết rằng đối với DB2 trên AIX, các DBA của chúng tôi nhận được 5 khối cho mỗi cơ sở dữ liệu - mỗi khối cho một phần khác nhau của DB. Một cho DB, một cho nhật ký chính, một cho nhật ký lưu trữ, tạm thời và một cái gì đó khác. Đó là khối lượng, chúng không phải là LUN, nó phụ thuộc vào cách bạn muốn quản lý bộ nhớ của mình.


Cần thêm chi tiết - anh ta muốn 38 LUN cho một DB, hay 38 LUN cho một DB PLUS bản dựng của máy chủ mới? Đó là Oracle trên Windows, hay Linux / Unix? Quản trị viên Linux / Unix có xu hướng muốn có nhiều phân vùng nhỏ hơn chỉ dành cho HĐH, trước khi bạn truy cập vào các ứng dụng và DB - / usr, / var, exchange, / etc, v.v. Tôi nghĩ rằng bạn cần có một cuộc thảo luận chi tiết với anh ấy, và cả hai bạn có thể cần phải nghiên cứu thêm. Anh ta có thể cần rất nhiều đĩa không chia sẻ vì lý do IO, ví dụ.
mfinni
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.